Supervisión del tiempo de respuesta

Por qué el tiempo de respuesta merece su propia alerta

Las alertas de uptime estándar se basan en una señal binaria: activo o caído. La zona gris intermedia —activo, pero lento— es donde realmente habita la mayoría de los fallos modernos. Una consulta mal configurada a la base de datos comienza a durar 4 segundos en vez de 50ms. Una fuga de memoria provoca picos de garbage collection. Una API externa a la que llama el backend comienza a fallar intermitentemente. Ninguna de estas cosas rompe la web por completo, pero la hace inutilizable — y son señales tempranas de una caída que puede ocurrir en una o dos horas.

El monitoreo del tiempo de respuesta detecta el deterioro antes de que sea una avería. Configuras un umbral por monitor, y cuando el tiempo de respuesta lo supera en varias comprobaciones consecutivas, recibes una alerta. Antes de que salte la alerta, aún tienes margen para investigar el asunto, escalar recursos, limitar la llamada problemática o revertir el despliegue que lo causó.

Cómo funcionan los umbrales en DiagnoSEO Uptime Monitoring

Cada monitor se puede configurar con dos parámetros: rt_threshold_ms y rt_threshold_breaches. El primero es el tiempo de respuesta en milisegundos que consideras aceptable. El segundo es el número de comprobaciones consecutivas que deben superarlo para que se dispare una alerta. Por defecto, el umbral está desactivado, y el número de superaciones es tres.

El diseño con dos parámetros protege de falsos positivos. El jitter de red sucede. Las pausas de garbage collection suceden. Un único pico de 1 segundo contra una base de 200ms no merece que te despierten a las 3 de la mañana. Pero tres respuestas seguidas de 1 segundo sí — ya es una ralentización sostenida, no un parpadeo. Escoge el umbral según el comportamiento normal observado más un margen razonable: si el p95 suele ser 400ms, un umbral de 1000ms. Si el p95 es 50ms (API interna), un umbral de 200ms.

Con qué combina bien

Las alertas de tiempo de respuesta funcionan mejor en combinación con otras señales del monitor. Una visión completa: el umbral de tiempo de respuesta te dice que el sistema se está degradando; el código HTTP te dice cuándo realmente falla; las alertas de SSL/dominio — de caídas provocadas por el reloj; las alertas de cambios DNS — de desviaciones de configuración. Juntas, estas cuatro señales en el mismo monitor convierten el binario “¿funciona?” en una observabilidad completa.

El panel de control también ayuda. Cada monitor muestra un sparkline de los últimos tiempos de respuesta — un indicador visual rápido de patrones de degradación. La vista ampliada muestra las medias de 24h, 7d y 30d. Si ves la media subiendo semana a semana — es una señal temprana que merece ser investigada antes de que supere el umbral de alerta.

Umbrales prácticos según tipo de página

• Páginas de aterrizaje de marketing: 1500ms es razonable. Suelen estar cargadas de imágenes y scripts de seguimiento; la velocidad absoluta importa menos que la estabilidad.
• Páginas de producto/categorías de ecommerce: 800-1200ms. Un ecommerce lento mata las conversiones; umbrales más estrictos detectan problemas antes.
• Dashboards de aplicaciones: 500-800ms. Los usuarios esperan inmediatez. Un dashboard lento hace que el producto parezca roto.
• API públicas: 200-400ms para endpoints simples, más para operaciones pesadas. Diferéncialas por niveles.
• Health checks de microservicios internos: 50-100ms. Deberían ser prácticamente instantáneos; la lentitud casi siempre indica un problema real.

Sea cual sea el umbral que escojas, no lo dejes fijo para siempre y te olvides. Revalúalo trimestralmente según las tendencias reales que observes. Si recibes constantemente alertas de superación que no representan problemas reales — el umbral es demasiado estricto. Si tienes una caída sin una alerta previa de umbral — era demasiado laxo.

Enrutamiento de alertas

Las alertas por exceder el umbral van por los mismos canales que las alertas de caída/recuperación: Email, Telegram, Slack, Discord, SMS. Respetan el mismo silencio nocturno. Se registran en la misma tabla de alertas. La única diferencia es el tipo de evento (“threshold” en vez de “down”) y el contenido del aviso — indica el tiempo de respuesta actual y el umbral configurado, por lo que ves de inmediato cuánto se ha superado.

Configuración

Edita cualquier monitor. En el formulario, configura el “Umbral de tiempo de respuesta (ms)” con el valor que desees. Opcionalmente ajusta las “superaciones consecutivas” si las 3 por defecto no se adaptan a tu tolerancia. Guarda. Desde el siguiente ciclo, cada comprobación compara el tiempo de respuesta con el umbral, y tras el número configurado de superaciones consecutivas, recibirás una notificación.

Preguntas frecuentes

• ¿Qué métrica de tiempo de respuesta se registra?

  Time To First Byte (TTFB): milisegundos entre el envío de la solicitud y la recepción del primer byte de la respuesta. Además, el tiempo total para descargar la respuesta completa. El TTFB es la métrica individual más útil para la salud del servidor.

• ¿Cuál es un “buen” tiempo de respuesta?

  Depende de la ubicación y el contenido. Para una página estática con CDN: menos de 100ms es excelente, menos de 300ms está bien. Para aplicaciones dinámicas: menos de 500ms está bien, menos de 1000ms es aceptable, más de 2000ms parece lento. Compara con tu propia base histórica en vez de números absolutos.

• ¿Puedo recibir una alerta si el tiempo de respuesta supera el umbral?

  Sí. Cada monitor tiene un umbral de tiempo de respuesta opcional. Si 3 comprobaciones consecutivas superan el umbral, recibes una alerta de “respuesta lenta”. El requisito de 3 comprobaciones evita falsas alarmas por cortes de red puntuales.

• ¿Desde dónde se mide el tiempo de respuesta?

  Desde nuestros 13 puntos de comprobación geográficos (Europa, América del Norte, Asia, América del Sur, Oceanía). Para monitores de una sola región, los tiempos provienen de la región más cercana. Para monitorización multi-región, cada región se mide por separado — útil para detectar problemas regionales en el CDN.

• ¿El dashboard muestra tendencias de tiempo de respuesta?

  Sí — media móvil de 30 días, máximos/mínimos diarios y percentiles (p50, p95). Útil para planificar capacidad: si el p95 subió de 800ms a 1500ms en un mes, tus servidores se están sobrecargando aunque el % de uptime siga al 100%.