Los log levels son etiquetas de severidad que acompañan a cada entrada del registro. Controlan qué se guarda, qué se muestra y qué dispara una alerta. El estándar dominante define cinco niveles — DEBUG, INFO, WARN, ERROR, FATAL — en orden creciente de severidad. El valor central del sistema de niveles: mantener el ruido al mínimo en operación normal y, cuando algo falla, filtrar y alertar rápido por nivel.
Referencia rápida: los cinco niveles estándar
| Nivel |
Significado |
Contenido típico |
Producción |
Alerta |
| DEBUG |
Detalle de depuración |
Valores de variables, sentencias SQL, argumentos de función |
Apagado |
No |
| INFO |
Hitos normales del negocio |
Login de usuario, pedido creado, tarea iniciada |
Encendido |
No |
| WARN |
Anómalo pero autorrecuperado |
Reintento con éxito, fallback activado, petición lenta |
Encendido |
Agregar y revisar a mano |
| ERROR |
Falló la operación actual |
API 5xx, pago rechazado, puntero nulo |
Encendido |
Sí |
| FATAL |
Caída a nivel de sistema |
Base de datos inalcanzable, el servicio no arranca |
Encendido |
Sí (respuesta P0) |
Cómo decidir el nivel correcto
En la práctica, usar mal los niveles es más común que la falta de logs. Criterios aplicables:
DEBUG: para los ojos del propio desarrollador
- Criterio: esa información no vale nada mientras el sistema funciona con normalidad y solo sirve para investigar un bug concreto;
- Contenido típico: argumentos y retornos de funciones, resultados intermedios, aciertos de caché;
- Principio clave: apagado por defecto en producción. No borrado — filtrado, para poder activarlo puntualmente cuando hay problemas.
INFO: para quien pregunta «qué está haciendo el sistema»
- Criterio: releer esta entrada medio año después permite reconstruir el recorrido del usuario;
- Contenido típico: acciones clave del negocio (registro, compra, publicación), inicio/fin y duración de tareas;
- Antipatrón: registrar cada HTTP 200 como INFO — ese es el trabajo del log de acceso; no contamines el log de negocio con eso.
WARN: algo falló, pero el sistema lo aguantó
- Criterio: alguien debería saberlo, pero nadie tiene que levantarse a las 3 de la mañana;
- Contenido típico: éxito tras reintento, limitación/degradación activada, duración de petición por encima del umbral;
- Señal de riesgo: una subida repentina de WARN suele preceder a los ERROR — conéctala a monitorización de tendencias.
ERROR: una acción del usuario falló
- Criterio: si no se arregla, el usuario volverá a toparse con el mismo problema;
- Contenido típico: llamada a un servicio externo fallida, excepción de validación, error no capturado;
- Requisito clave: cada ERROR debe traer contexto (URL, ID de usuario/tenant, parámetros de la petición, stack trace), si no, es solo ruido inacciónable.
FATAL: el sistema ya está caído
- Criterio: el servicio como conjunto ya no puede funcionar;
- Contenido típico: fallo de conexión a la base de datos, falta configuración imprescindible, arranque fallido;
- Consejo práctico: FATAL es raro en aplicaciones web — la mayoría de los «está todo caído» se manifiesta como una avalancha de ERROR, cubierta por una alerta de «pico súbito de ERROR». No abuses de FATAL o diluirás su severidad.
Los niveles en la Consola del navegador
Los niveles del front comparten nombre con el back pero hacen menos. La Consola soporta de forma nativa:
| Método |
Nivel en la Consola |
Uso |
console.debug() |
Debug (oculto por defecto; activar Verbose) |
Depuración en desarrollo |
console.log() |
Info |
Salida general |
console.info() |
Info |
Igual que arriba, más explícito |
console.warn() |
Warning, amarillo |
Avisos de problemas recuperables |
console.error() |
Error, rojo, con stack trace |
Fallos y excepciones no capturadas |
Dos consejos prácticos:
Escribe la depuración del front con console.debug en vez de console.log — el build de producción la esconde tras el filtro por defecto, sin limpieza manual;
Las excepciones no capturadas (window.onerror / unhandledrejection) son de nivel ERROR por defecto y son la primera pista en producción.
El problema especial del front: los usuarios no recogen logs por ti
Los logs del back viven en los servidores, listos para consultarse en cuanto aparece un problema. Los del front quedan dispersos en el navegador de cada usuario — el usuario reporta «la página está rota», y los errores de Console y las peticiones fallidas desaparecen con esa sesión de página. Cuando el usuario sigue un tutorial para abrir DevTools (pasos en cómo abrir la consola del navegador), un refresh ya se ha llevado los errores por delante.
La pregunta que debe responder una estrategia de logs de front no es «cómo asignar niveles», sino «cómo conservar los logs del instante exacto del fallo». Enfoques habituales:
| Enfoque |
Cómo funciona |
Coste |
| Reporter propio |
Enviar toda la salida de console al servidor |
Alto coste de almacenamiento/privacidad; el muestreo es difícil de ajustar |
| Plataforma de monitorización front |
Captura completa + reproducción de sesión |
Pago por volumen; caro para equipos pequeños y medianos |
| Captura bajo demanda (adjunta al informe de bug) |
Al enviar feedback, los errores Console/Network de ese momento se adjuntan solos |
Coste mínimo; cubre «reportado por el usuario», la mayor fuente de todas |
El tercer enfoque encaja de forma natural con el informe de bug: el momento en que el usuario reporta un bug es exactamente el momento en que importan los logs.
BugCapturer aplica precisamente esta captura bajo demanda: cuando un usuario (aunque sea totalmente no técnico) envía una captura/grabación anotada desde la extensión o el SDK incrustado, el informe lleva automáticamente los errores de Console del momento (con stack traces de ERROR) y las peticiones Network fallidas, además de la URL y el entorno del navegador (ver la función de diagnóstico). El informe llega al desarrollador con el contexto de logs ERROR ya adjunto — se acabó el «abre F12 y cópialo». Los informes se comparten con un enlace sin inicio de sesión, o se empujan automáticamente a un canal de Slack / Microsoft Teams para un seguimiento centralizado.
Errores habituales
| Error |
Práctica correcta |
Todo con console.log, sin limpiar nunca |
Usar niveles: debug para depurar, info para hitos de negocio, eliminar debug en el build |
| Registrar fallos como INFO «para no asustar a ops» |
Un fallo es un ERROR; la alerta depende de los niveles, no de que alguien lea los logs |
| ERROR con un mensaje y sin contexto |
Adjuntar siempre URL, parámetros y stack — si no, no has registrado nada |
| DEBUG activado por todas partes «para depurar más fácil» |
Los niveles son un filtro: DEBUG apagado normalmente, activado a demanda cuando surge el problema |
| WARN acumulándose sin que nadie lo trate |
Llevar los WARN a alertas de tendencia; un pico es el presagio de los ERROR |
FAQ
P: ¿Cuántos log levels existen?
R: El estándar dominante son cinco — DEBUG, INFO, WARN, ERROR, FATAL. Algunos frameworks (Syslog, sistemas tipo Trace) añaden variantes TRACE/NOTICE/CRITICAL, pero su semántica se corresponde una a una con la tabla de arriba.
P: ¿Cómo se eligen y configuran los logging levels?
R: Todo encendido en desarrollo (desde DEBUG), desde INFO o WARN en producción; ERROR dispara alertas, WARN alimenta la monitorización de tendencias. Configura las librerías por separado del código de negocio para que el DEBUG de una dependencia no lo inunde todo.
P: ¿El front necesita niveles de log como el back?
R: Sí, pero simplificados: con cuatro niveles — debug / info / warn / error — basta. Lo importante es que ERROR traiga stack trace y resolver el problema de «conservar los logs del instante del fallo».
P: ¿Cómo consigo que los usuarios me manden los errores de Console al reportar un bug?
R: Pedirles a usuarios no técnicos que copien errores es misión imposible. Usa una herramienta como BugCapturer que capture automáticamente los errores Console/Network al enviar — ver la sección de «captura bajo demanda» más arriba.