Errores silenciosos: cuando tu sistema miente sin darse cuenta

El problema que nadie ve hasta que es tarde

Hace poco un cliente me escribió preocupado: «Humberto, nuestro sincronizador de inventario reporta que todo está bien desde hace tres meses, pero acabo de revisar y hay productos con stock incorrecto». La tarea programada se ejecutaba cada noche, marcaba «exitoso» en los logs, y nadie sospechaba nada. El error estaba adentro: la API del proveedor había cambiado su formato de respuesta, y el sistema seguía «procesando» datos vacíos sin quejarse.

Esto ocurre más de lo que piensas. No es un bug ruidoso que te avienta un error en la cara. Es algo peor: un silencio falso que te hace creer que todo funciona mientras los datos se pudren por debajo.

Tres tipos de errores silenciosos que debes conocer

1. La tarea que reporta éxito sin hacer nada

Un script programado se ejecuta, registra «completado», pero nunca tocó los datos. Puede pasar por:

• Una conexión a base de datos que falló pero el error fue capturado y ignorado.
• Un archivo que debería existir pero no está, y el programa simplemente saltó esa parte.
• Una condición lógica que nunca se cumplió, así que nada pasó, pero el script terminó «bien».

El resultado: crees que tus datos están sincronizados, importados o procesados cuando en realidad siguen igual que ayer.

2. La API que corta resultados en silencio

Algunos servicios externos tienen límites de respuesta que no comunican bien. Piden 500 registros, reciben 100 (el máximo permitido), pero el servidor responde «200 OK» como si todo fuera normal. Ni siquiera un aviso de «hay más datos disponibles».

Ves tus números redondos (100, 500, 1000) y debería ser una señal: probablemente fue truncado. Especialmente si ayer tenías 250 registros y hoy exactamente 200.

3. El proceso que envuelve el error dentro del OK

Una factura se registra «exitosamente», pero uno de los campos obligatorios quedó vacío o malformado. Un pedido se envía al proveedor pero la cantidad está corrupta. El sistema respondió OK, pero si no verificas los datos después, descubrirás el problema cuando ya sea tarde.

Cómo detectarlos antes de que causen daño

Verifica los datos después, no solo el reporte

No confíes en que un log diga «éxito». Mira lo que realmente pasó: ¿Los registros se actualizaron? ¿El contador cambió? ¿Los datos tienen sentido?

Hace un tiempo detecté que un sistema de importación de catálogos reportaba «200 productos importados» cada día, pero el total nunca subía. Revisé los datos: importaba y borraba los mismos 200 productos en un loop. Parecía éxito, era un desastre.

Configura alertas por ausencia

Si algo debería pasar cada día (una sincronización, una importación, un reporte), crea una alarma que dispare si NO pasó nada en N días. No solo si falló, sino si no hubo cambio.

Ejemplo: «Si en los últimos 3 días no hay nuevos registros en la tabla de sincronización, enviar alerta». Esto atrapará tareas que se ejecutan pero no hacen nada.

Desconfía de los números redondos

Si ves exactamente 100, 500, 1000 registros, pregúntate: ¿Es coincidencia o un límite? Verifica si hay una siguiente página, un parámetro de paginación sin usar, o un tope hardcodeado en el código.

El costo real de ignorar esto

Un error silencioso no es un inconveniente, es un sangrado lento. Datos incorrectos se propagan: un inventario mal sincronizado genera ventas de stock que no existe. Una factura con campos vacíos genera rechazos en la plataforma fiscal. Un catálogo truncado significa que clientes no ven tus productos completos.

La diferencia entre un error que grita y uno que susurra es que el segundo te roba tiempo y dinero mientras tú sigues adelante sin saber.

Cierra con auditoría, no con fe

La solución no es perfecta: es pragmática. Revisa los datos, configura alertas por ausencia de cambio, y cuestiona cualquier número que parezca demasiado redondo. Cuando construyo sistemas para mis clientes con Hailan, siempre agrego estos checkeos: logs detallados, alertas de inactividad, y validaciones que verifiquen que lo que reporta el sistema es lo que realmente ocurrió en los datos. Porque un «exitoso» falso es peor que un error que te despierta a las 3 de la mañana.