Logs sin saturación: qué mirar y qué ignorar
| Fase | F4 — Diagnóstico, calidad y contingencias |
|---|---|
| Módulo | M4.1 — Logs sin saturación |
| Puntos de profesionalidad al superar el test | 30 |
Objetivo práctico
Al terminar esta lección sabrás leer un registro (log) de cualquier plataforma de este curso sin sentirte desbordado, localizando con rapidez, mediante búsqueda por teclado, exactamente el dato que necesitas, e interpretando los códigos de estado HTTP más frecuentes.
Resultado que obtendrás
Capacidad de abrir cualquier panel de logs del curso y encontrar, en menos de un minuto, la línea relevante para un fallo concreto, en lugar de leer el registro entero de principio a fin.
Dónde encaja dentro del sistema final
Este módulo abre la Fase 4, dedicada al diagnóstico. Los logs son la fuente de información más fiable de todo el sistema: no dependen de lo que tú creas que ha pasado, sino de lo que realmente ha ocurrido en cada pieza.
Conocimientos previos
- El flujo completo de la llamada (módulo 1.2).
- Webhooks: request, response (módulo 3.1).
Herramientas necesarias
- Un navegador con NVDA activo.
Posible coste
Esta lección es conceptual y no requiere ningún gasto.
Modelo mental
Piensa en el libro de incidencias de una oficina: no lo lees entero cada vez que buscas un dato, buscas la fecha, el número de expediente o la palabra clave concreta. Un log es exactamente ese libro, y la búsqueda por teclado es tu forma de encontrar la línea exacta sin leer las demás.
Explicación
Un log (registro) es un archivo o listado, ordenado normalmente por tiempo, que anota lo que ha ido ocurriendo en un sistema. Cada entrada suele incluir, como mínimo, un timestamp (marca de tiempo exacta), un nivel de gravedad (error: algo ha fallado; warning: algo merece atención pero no ha impedido el funcionamiento), y los datos técnicos del suceso: qué request (petición) se envió, qué response (respuesta) se recibió, un ID que identifica ese suceso concreto (útil para buscarlo después), su duración y su latencia (ya vistas en el módulo 1.2).
El error más habitual al enfrentarse a un log por primera vez es intentar leerlo entero, línea por línea, de arriba a abajo. La técnica correcta, sobre todo con NVDA, es exactamente la contraria: usar Ctrl + F para buscar algo concreto —una fecha, un ID de llamada, la palabra «error»— y leer sólo esas líneas.
Al diagnosticar, aplica siempre el método TELEFONÍA → CEREBRO → VOZ → AUTOMATIZACIÓN → CALENDARIO ya usado en todo el curso: identifica primero en qué pieza ocurrió el problema, y sólo entonces abre el log de esa pieza concreta, no los cinco a la vez.
Los códigos de estado HTTP aparecen constantemente en los logs de todas las plataformas de este curso. Los más frecuentes: 400 (petición mal formada, normalmente un error en el JSON enviado); 401 (no autenticado, credenciales ausentes o incorrectas); 403 (autenticado pero sin permiso para esa acción); 404 (el recurso solicitado no existe, por ejemplo una URL de Webhook mal escrita); 408 (tiempo de espera agotado, timeout, del lado del cliente); 409 (conflicto, por ejemplo intentar reservar un hueco ya ocupado); 429 (demasiadas peticiones en poco tiempo, rate limit); 500 (error interno del servidor receptor); 502 y 503 (el servidor intermedio o el servidor final no responde correctamente, a menudo temporal). Un timeout genérico significa que una petición no obtuvo respuesta dentro del tiempo esperado, sin que necesariamente haya un código de error explícito.
Vocabulario nuevo
Timestamp
Piénsalo así: El sello de fecha y hora que se estampa en cada documento que entra en una oficina.
Marca de fecha y hora exacta asociada a una entrada de un log.
Ejemplo: El timestamp de una llamada fallida te permite localizarla exactamente en varios logs distintos, comparando la misma franja horaria.
ID de llamada / execution / request
Piénsalo así: El número de expediente que identifica sin ambigüedad un caso concreto en varios departamentos distintos.
Identificador único de un suceso concreto, que permite localizarlo en distintos sistemas (por ejemplo, en el log de Vapi y en el de n8n) como el mismo caso.
Ejemplo: El Call ID de Vapi te permite buscar la misma llamada en el historial de ejecuciones de n8n.
Rate limit
Piénsalo así: El límite de peticiones que un departamento puede atender por minuto antes de empezar a rechazar nuevas solicitudes.
Límite de número de peticiones que una API acepta en un periodo de tiempo; superarlo produce normalmente un código 429.
Ejemplo: Enviar demasiadas peticiones de prueba seguidas a una API puede activar su rate limit y devolver un 429 temporal.
Preparación
No se requiere preparación técnica.
Procedimiento paso a paso
Contexto: Vas a practicar la búsqueda dirigida en un log real: el historial de ejecuciones de tu workflow de n8n o de tu escenario de Make (módulo 3.3).
Acción de teclado: Abre el historial de ejecuciones y pulsa Ctrl + F para buscar la palabra «error», aunque no esperes encontrar ninguna si tus pruebas anteriores funcionaron correctamente.
Respuesta esperada de NVDA: NVDA debería anunciar «Frase no encontrada» si no hay errores, o resaltar la primera coincidencia si la hay.
Qué significa: Confirmas que la técnica de búsqueda dirigida funciona igual en un panel real que en cualquier página web.
Acción siguiente: Repite la búsqueda con el ID de una de tus ejecuciones de prueba anteriores, si lo tienes anotado.
Contexto: Vas a practicar la interpretación de un código de estado HTTP con un ejemplo controlado.
Acción de teclado: Repite el ejercicio del módulo 3.1: envía una petición a tu URL de prueba de webhook.site sin ningún dato en el cuerpo, y localiza en el panel el código de estado devuelto.
Respuesta esperada de NVDA: NVDA debería anunciar el código de estado junto al resto de detalles de la petición.
Qué significa: La mayoría de peticiones simples devuelven 200; si alguna vez ves 400, 404 o 500 en tus propias pruebas, ya sabes qué familia de problema representa cada uno.
Acción siguiente: Anota, en tu documento de configuración técnica, una tabla breve con los códigos de esta lección para consulta rápida futura.
Errores frecuentes y diagnóstico
Sentirse abrumado al abrir un log largo por primera vez.
Cómo localizarlo: Es una reacción habitual si se intenta leer todo el registro de arriba a abajo.
Solución: Usa siempre Ctrl+F con un dato concreto (timestamp, ID, o la palabra «error») antes de leer nada más.
Comprobación final
Explica en voz alta qué diferencia hay entre un código 401 y un código 403, y entre un 404 y un 500. Si tu explicación es correcta sin mirar la lección, la comprobación es positiva.
Qué acabas de conseguir
Tienes la técnica y el vocabulario necesarios para leer cualquier log del resto de este módulo sin sentirte desbordado.
Ejercicio práctico
Para cada uno de estos síntomas, indica qué código de estado HTTP de esta lección esperarías ver en el log: (1) enviaste un JSON con un error de sintaxis; (2) tu clave de API ha caducado; (3) intentaste acceder a una URL de Webhook que ya no existe.
Resumen de lo imprescindible
- Un log se compone, como mínimo, de timestamp, nivel de gravedad, request, response, ID y duración.
- La técnica correcta es la búsqueda dirigida con Ctrl+F, no la lectura completa de arriba a abajo.
- Diagnostica primero qué pieza del sistema falló (método TELEFONÍA → CEREBRO → VOZ → AUTOMATIZACIÓN → CALENDARIO) y abre sólo el log de esa pieza.
- Códigos frecuentes: 400 (petición mal formada), 401 (sin autenticar), 403 (sin permiso), 404 (no existe), 429 (demasiadas peticiones), 500/502/503 (error del servidor).
No necesitas aprender todavía
Todavía no necesitas saber exactamente dónde está cada log en cada plataforma concreta: es el contenido de la siguiente lección.
Estoy preparado para continuar si puedo…
- Explicar qué información contiene, como mínimo, una entrada de log.
- Usar la búsqueda dirigida con Ctrl+F en lugar de leer un log completo.
- Interpretar correctamente los códigos de estado HTTP más frecuentes.
Fuentes
- HTTP response status codes — MDN Web Docs (Mozilla) (consultado el 2026-08-30)
- Workflow-level executions — n8n (consultado el 2026-08-30)
- Troubleshooting Twilio — Twilio (consultado el 2026-08-30)
Última actualización de esta lección: 2026-08-30.
Test de la lección
Para realizar el test y obtener Puntos de profesionalidad necesitas iniciar sesión o crear una cuenta.
Navegación
Lección anterior: Hito: llamada completa con cita confirmada en el calendario
Continuar con la siguiente lección: Dónde están los logs en cada plataforma del sistema