¿Qué es lo primero que reviso cuando algo sale mal en producción? Los logs, claro. Soy CTO de Tupaca, una software factory de Argentina, y en estos años aprendí que una de las cosas que más le cuesta a los devs es armar logs útiles.
TL;DR
- Los mejores equipos de IT del mundo logran recuperar caídas de sistemas críticos en menos de 1 hora (según las métricas DORA).
- El costo promedio por cada hora de downtime asciende a 2 millones de USD. Parece mucho, pero es real. En la nota explico de dónde surge ese número y cómo se compone.
- Para reducir al máximo esos tiempos, es fundamental escribir logs útiles siguiendo una serie de reglas claras:
- Ser claro en el mensaje. Ser empático . Pensar en quien lo va a leer.
- Dar contexto útil (cuándo, dónde, quién, qué).
- Respetar la capa de abstracción.
- Loguear bien los errores (stack trace y contexto).
- Generar trazabilidad (no loguear solamente errores, sino también eventos clave).
- Usar formato estructurado (JSON).
- Asegurarse de capturar también errores críticos.
- Segurizar datos sensibles (enmascarar, nunca exponer en logs).
- Generar skills para que tus agentes IA sepan cómo loguear correctamente.
- Estas buenas prácticas no alcanzan si dependen de individuos: deben estar institucionalizadas en políticas y procedimientos para que formen parte de la cultura del equipo que construye el software.
Síntomas de que esta nota es para vos
🔸 Te enterás de los problemas que hay en producción porque te lo avisa el cliente o un usuario.
🔸 Para entender un log tenés que buscar en qué parte del código se dispara, para recién ahí entender el contexto (y ni que hablar si al buscarlo encontrás más de un lugar en donde se dispara y no sabés cuál de todos es).
🔸 Tardás más de 15 minutos en entender cuál es el problema (no me refiero a la causa, sino al problema).
🔸 Para entender una falla en un sistema tenés que agregar más logs en producción y esperar a que vuelva a ocurrir, para recién ahí ver si podés entenderla 😅.
🔸 Recibís alertas de logs que no requieren que nadie tome ningún tipo de acción.
🔸 Se murió el sistema porque los logs llenaron el disco.
🔸 Las personas responsables de leer los logs no saben cómo o dónde hacerlo.
Si alguna de estas cosas te suena conocida, ¡esta nota es para vos!
Si preferís formato video: estuve en Nerdearla 2025 Buenos Aires, hablando sobre este tema. Te lo dejo acá:
El costo real de un sistema caído
Como devs, nos duele enormemente ver a nuestros sistemas caídos, a los que tanto amor y esfuerzo les dedicamos, para que sean perfectos, cumplan con cada caso de uso, sean super mantenibles… Nos duele en el alma.
Pero que se caiga un sistema no es solo un dolor técnico. Es plata, mucha plata.
Tenemos que tener en cuenta:
- Costos operativos: desvío de devs que deberían estar creando features nuevos, horas extra, etc.
- Costo de oportunidad: la empresa probablemente no produce o no factura mientras el sistema está caído. Si tenés un e-commerce, cada minuto sin ventas es dinero perdido y probablemente de forma irreversible.
- Reputación: la confianza del cliente es lo más difícil de recuperar. Si se nos va un cliente, el costo no va a ser solamente el tiempo que dure la caída. Es toda la facturación de ese cliente.
- Penalidades (SLA) / litigios: contratos incumplidos = multas.
En promedio, una hora de downtime cuesta 2 millones de dólares a nivel global. Parece un número ridículamente alto, pero pensá en empresas que mueven todo por sistemas digitales: cada segundo sin servicio multiplica pérdidas en ventas, contratos y confianza.
Este número viene en ascenso desde hace mucho tiempo. Y tiene sentido… Cada vez más incorporamos tecnología a procesos críticos de nuestras empresas.
DORA y el tiempo de recuperación
Los equipos top del mundo se miden con las métricas DORA. Una de las más relevantes es el TTRS (Time to Restore Service): cuánto tardás en levantar un sistema caído. Otras métricas lo llaman “MTTR”.
- Menos de 6 meses → bajo desempeño.
- Menos de 1 semana → medio.
- Menos de 1 día → alto.
- Menos de 1 hora → elite.
Guau. elite, suena muy groso. Y lo es. Llegar a esa categoría no es magia: se trata de procesos, cultura y, sobre todo, observabilidad.
Ese tiempo no se reparte parejo. En la mayoría de los incidentes se divide así:
- 10% detección: darte cuenta que el sistema se cayó.
- 70% investigación y análisis: entender qué pasó.
- 20% resolución: el fix en sí, el deploy y el post mortem.
Ojo con ese 70%. No es tan contraintuitivo si lo pensás: encontrar la causa de un error lleva horas, y cuando la encontrás, muchas veces es una boludez — un punto y coma, un typo. Ahí es exactamente donde pegan los logs útiles: no te ayudan a arreglar más rápido, te ayudan a entender más rápido. Y ese 70% es la parte del TTRS que más se puede recortar sin tocar una sola línea de código de producción.
Observabilidad: ver todo para resolver más rápido
Si no podés ver lo que pasa en tu sistema, no podés arreglarlo.
Las herramientas de observabilidad lo son todo, nos ayudan MUCHÍSIMO. Vas a poder ver logs en tiempo real, trazas, dashboards con métricas, establecer alertas ante determinadas situaciones (por ejemplo cuando hay un log de error) para que te lleguen al celular, correlacionar los logs que ocurren en un subsistema con los de otro (por ejemplo los del back y el front, o entre distintos microservicios), y millones de cosas más. Algunas que te recomiendo: New Relic, Splunk, ELK. Sugiero que si no conocés ninguna, te pongas en campaña para investigarlas.
Las empresas que invierten en observabilidad completa logran reducir un 80% su TTRS y, en consecuencia, los costos de downtime, reduciendo de 2 millones de dólares por hora a 1 millón de dólares por hora (según un estudio de NewRelic de 2025)
Y sin embargo, según el mismo reporte de NewRelic, solo el 27% de las empresas tiene observabilidad full-stack implementada. El 73% restante está, en mayor o menor medida, operando a ciegas.
Pero todos hablan de observabilidad, y nadie dice algo que es fundamental:
Sin LOGS ÚTILES la observabilidad no sirve tanto
Logs útiles
Uno de los pilares de la observabilidad son los LOGS.
Logs: registros que el desarrollador dejó adrede en el código para que vayan explicando, con lenguaje humano, lo que va pasando durante la ejecución del sistema
¿Pero qué es un log útil? Esto no:
[ERROR] - Ups! Esto no debería haber pasado.
Ponete en el lugar de la persona que está leyendo ese log, urgido porque el sistema está caído. No entiende nada. Típicamente va a ir a mirar el código, para entender dónde se ejecuta ese log, y así ver si puede entender algo más.
¿Y si en vez de ese log, el dev hubiera explicado qué pasó? Por ejemplo:
[ERROR] - Se obtuvo un exchange rate menor a cero desde el Banco Nación.
Mucho más útil, ¿no?
Se trata de EMPATÍA. Tenemos que pensar en el otro, en la persona que va a necesitar leer esos logs.
Y ojo, que un log poco claro ya es grave. Pero hay un nivel peor: el log que miente. Un webhook escuchando confirmaciones de transferencias: alguien copió el código del caso “transferencia realizada”, lo adaptó para “transferencia rechazada”… y se olvidó de cambiar el mensaje del log. Resultado:
[INFO] - Transferencia realizada.
Cuando en realidad se había rechazado. Imaginate el lío para quien investiga por qué un cliente dice que nunca le llegó la plata, mientras el log le jura que salió todo bien.
Las 9 reglas de oro para escribir buenos logs
- Ser claro en el mensaje. Ser empáticos pensando en quien lo va a leer, explicar las cosas de forma clara.
- Dar contexto útil. Cuándo, dónde, quién y qué. Siempre:
- Fecha y hora:
[1945-10-17 00:00:00]¡Fundamental! En mi experiencia, me crucé con infinidad de sistemas que loguean sin fecha y hora. La única pista que tenés ahí es cuál vino antes y cuál después. ¿Pero cuándo? ¿Ayer? ¿El año pasado?🤦 - Nivel de criticidad:
INFOWARNERRORCRITICAL. De esta forma le podemos explicar a quien lee el log (y a las herramientas), si es un problema o no. - Del sistema y negocio:
url user_id, ipy toda la info que consideres que puede llegar a ser útil de qué estaba pasando a nivel sistema y a nivel negocio (si falló el pago de una orden, “¿cuál orden?”) . Y es super importante que esta info esté estandarizada en todos nuestros logs. De lo contrario, no vamos a poder manipularlas con comodidad desde las herramientas de observabilidad. Hay algunas convenciones al respecto, por ejemplo de OpenTelemetry (ver acá). - Del código: ¿Dónde ocurrió el log? ¡Es super util tener esta info¡ Por ejemplo:
archivo.js:78 nombreDeLaFuncion(). Pero no olvidar los “Source maps”: cuando llevamos nuestro código a producción, muchas veces sufre modificaciones (ya sea porque se compila, o porque se transforma para ser más performante). Si nuestro log nos va decir que el log se ejecutó enjcc-123.js:10 a2N(), necesitamos de un “diccionario” que nos traduzca eso a la línea de código real que nosotros realmente conocemos:file.ts:11 nombreDeLaFuncion(). Eso lo resuelven los source maps.
- Fecha y hora:
- Respetar la capa de abstracción. No tires cualquier error en cualquier nivel sin siquiera mirar qué fue lo que pasó. Como mínimo explicá qué estabas haciendo. Por ejemplo, en este caso:
estamos “escupiendo” un error de super bajo nivel, sin saber cuál es el error, directo hacia los logs, sin sumarle absolutamente nada de contexto. Super distinto seríatry {...} catch (e) { console.error("Error obteniendo los datos del usuario mientras hacía una compra", e) }Así que TOTALMENTE PROHIBIDO hacertry {...} catch (e) { console.error(e) } - Loguear bien los errores. Usá las herramientas que te da el lenguaje que estás usando.
- Por ejemplo, casi todos te van a dar un “stack trace” que es algo así como el registro de todo lo que estaba pasando cuando saltó el error, y dónde saltó.
- Muchos lenguajes también te van a permitir crear tus propios errores/excepciones. Y es una herramienta tremendamente potente que veo que MUY pocos desarrolladores conocen y usan. Sugiero FUERTEMENTE que si no sabés de qué hablo, lo investigues. Y no solo sirven para modelar errores y así poder darles una capa adicional de abstracción, sino que vas a poder modelar flujos alternativos de tus casos de uso1.
- Generar trazabilidad. Logueá también eventos INFO, contando qué va pasando con el sistema (cosas esperables), no solo errores, con el objetivo de generar trazabilidad. Esto va a permitir generar un colchón de datos que van a serte muy útiles a la hora de entender qué fue lo que pasó.
- Formato estructurado (JSON). Es la única forma de sacarles bien el jugo a las herramientas de observabilidad, para que “entiendan” nuestros logs. No solo eso, sino que además, sin utilizar un formato estructurado, te va a ser imposible entender por ejemplo algo tan básico como dónde empieza y dónde termina un log.
- Capturar errores críticos. Muchos stacks tienen problemas para dejar guardados los logs cuando los errores son críticos (ejemplo: cuando se quedan sin RAM, sin espacio en disco, etc). Así es que muchos sabemos que cuando un sistema no levanta y no deja tampoco ningún log, muchas veces significa que nos quedamos sin espacio en disco. Pero eso requiere de conocimiento… Es importante que dediquemos esfuerzos para evitarlo y que eso no pase.
- Segurizar. Nunca expongas datos sensibles en logs: passwords, numeros de tarjetas de crédito etc. Hay herramientas que te ayudan a hacerlo de forma automática, pero lo ideal sería institucionalizar determinadas prácticas de redact en cada producto, y dejarlas establecidas para que a ningún dev se le escape.
- Enseñarle a la IA. La IA aprendió del código de millones de devs que cometen estos errores a diario. Por lo cual, estas prácticas no las va a tener en cuenta -por ahora-. Por lo cual, te sugiero que implementes skills a través de los cuales le puedas dar directivas a tus agentes IA de cómo tienen que hacer para escribir los logs, en donde estas prácticas las tenga siempre en cuenta.
Podés profundizar en guías como la checklist de Honeycomb sobre logging o el manual de Elastic.
Políticas y procedimientos: institucionalizar buenas prácticas
Acá está la diferencia entre “un dev prolijo” y “un equipo de elite”: institucionalizar. Que esto no dependa de que a alguien se le ocurra hacerlo bien ese día. Se define en 5 frentes.
1. Suite de herramientas
No alcanza con tenerlas. Hay que construir centralización y correlación entre sistemas (ver qué pasó en el front cuando explotó algo en el back, o viceversa), armar dashboards con las métricas vitales del negocio, y —esto es lo que casi nadie hace— asegurarse de que los interesados sepan usarlas. De nada sirve el mejor stack de observabilidad si, cuando explota algo, tenés a una persona leyendo logs en vivo mientras otra le dicta por teléfono “fijate los de ayer… no, filtrá por…”. Quien investiga tiene que tener acceso directo y saber moverse solo.
2. Proceso de desarrollo
Estandarizar los niveles (todo el equipo tiene que tener clarísimo cuándo algo es INFO, WARN, ERROR o CRITICAL), estandarizar el naming de los metadatos (¿user, user_id o userId? Elegí uno y que lo use todo el equipo, siempre) y definir qué herramienta de generación de logs usa cada stack. Sin esto, cada developer decide por su cuenta y las herramientas de observabilidad terminan sin poder agrupar ni buscar nada con consistencia.
3. Proceso de QA
Code review y testing tienen que meter los logs adentro de la revisión. Ponemos 400 comentarios discutiendo naming de variables, arquitectura, performance… y no decimos una palabra sobre los logs que se están agregando. Así es como se cuelan logs horribles a producción: nadie los mira hasta que ya es tarde.
4. Proceso de atención de incidentes
Hay que dejar por escrito: qué condiciones disparan una alerta, a quién y cómo se le avisa, qué prioridad tiene eso frente a lo que esa persona ya está haciendo (si estás desarrollando un feature y explota un sistema, ¿lo largás todo o seguís? Esa decisión no se toma en caliente, se define antes) y cuáles son los tiempos esperados de respuesta.
Una regla que no negocio: “nada” no es una respuesta válida a una alerta. Si te llega una y no te importa, el problema no es la alerta, es que está mal configurada — arreglá la condición para que no vuelva a saltar. Si te importa, actuá. Ignorarla sistemáticamente no es una opción: cada alerta ignorada te entrena a ignorar la próxima, que puede ser la real.
Bonus para el onboarding de guardias: cuando a un developer nuevo le toca su primera guardia, que esté presente (aunque sea de shadow) la primera vez que explota algo, viendo cómo se lee un log en un incidente real. Es más efectivo que cualquier documento.
5. Proceso de seguridad de la información
Definir qué datos son sensibles y enmascararlos de forma automática (no confiar en que cada dev se acuerde), y correr auditorías periódicas: tomar una muestra de logs de producción y revisar si se filtró algo que no debería estar ahí. Si cuidamos la seguridad de nuestros sistemas, tenemos que cuidar la de nuestros logs con el mismo nivel de exigencia — muchas veces terminan siendo la puerta de atrás que nadie audita.
Un último punto práctico: no hace falta una herramienta especial para documentar todo esto. Si tu empresa ya tiene procesos escritos para alguna certificación (ISO, por ejemplo), estas políticas van ahí. Si no, un doc compartido alcanza. Lo que importa no es dónde vive, es que exista y se use.
Así lo hacemos en Tupaca
En Tupaca definimos la política de logs como parte de la arquitectura de cada proyecto que desarrollamos, no como un afterthought post-lanzamiento: niveles estandarizados, contexto obligatorio (fecha, criticidad, usuario, request), formato estructurado desde el primer commit, y logging instructions documentadas para los agentes de IA que participan del desarrollo. No es un servicio aparte, es parte de cómo construimos software.
Conclusión
Un mal log puede costarte horas y millones. Un buen log puede ahorrártelos.
A los desarrolladores: cuando estén escribiendo código, acuérdense de esta nota antes de tirar un log sin pensar. Un log bueno cuesta lo mismo escribirlo que uno malo — la diferencia es si pensás 10 segundos en quién lo va a leer. Y si no son developers, díganselo a su amigo que sí lo es: “poné buenos logs”.
A management: pídanlo. La calidad de un sistema no se mide solo en código prolijo y performance — un sistema con el mejor código del mundo pero logs inútiles sigue tardando horas en recuperarse cuando algo se rompe. Exíjanlo como exigen testing o code review.
Y a todos: hagan la cuenta del costo real de una hora de downtime en su empresa. No es un ejercicio técnico, es un ejercicio de negocio — y una vez que la hacen, invertir en logs útiles deja de sonar a capricho de ingeniería.
¿Tu equipo necesita ayuda para implementar esto, o construir un sistema nuevo desde cero con estas prácticas ya adentro? En Tupaca lo hacemos todos los días — escribinos.
- Hay bibliografía en contra de esta práctica. Yo la considero tremendamente útil. ↩︎
