Poco antes de la medianoche, hora del Pacífico, el 19 de octubre de 2025, una condición de carrera en la automatización de DNS de Amazon DynamoDB dejó el endpoint regional del servicio en us-east-1 con un registro DNS vacío. Cualquier sistema que dependiera de DynamoDB en esa región comenzó a fallar, y los daños se extendieron a otros servicios de AWS dependientes. Según el resumen oficial de AWS, el incidente se prolongó durante unas catorce horas y media.
Aquella mañana, muchos equipos tenían sus servidores en perfecto estado. Sus monitores de disponibilidad permanecían en verde mientras su proveedor de autenticación, su pasarela de pagos o su servicio de correo atravesaban problemas críticos. La mayoría de las caídas son más sutiles: su proveedor de correo retrasa los envíos cuarenta minutos, soporte recibe una avalancha de tickets de «no me llega el correo para restablecer la contraseña» y alguien finalmente localiza la página de estado del proveedor, que lleva media hora mostrando «Rendimiento degradado».
Trabajo en Page Deltas, una herramienta que vigila páginas web públicas y le avisa cuando cambian según lo que le interesa; téngalo en cuenta cuando la compare con otras herramientas a continuación. Este artículo explica cómo dirigir la monitorización hacia las páginas de estado de sus proveedores clave: qué URL elegir, cómo redactar un brief que elimine el ruido innecesario, dónde recibir las alertas y qué limitaciones debe considerar.
Por qué su monitorización permanece en verde
Su monitor de disponibilidad consulta si su propio sitio responde, y durante una caída de un proveedor externo, casi siempre responde con éxito. Su herramienta de APM registrará un pico de errores en las llamadas salientes a dicho proveedor, pero no podrá aclararle si el problema se debe a su código o al servicio externo. Esa es justo la pregunta que resuelve una página de estado, y su respuesta cambia sus próximas acciones: no revierte el despliegue realizado hace una hora; informa a soporte de que es un fallo externo conocido y valora actualizar su propia página de estado.
Entonces, ¿por qué no suscribirse directamente en la página del proveedor? Debería hacerlo si cubre sus necesidades. Muchas páginas de estado se ejecutan en Atlassian Statuspage y permiten suscripciones por correo, SMS, Slack, Teams o webhooks, dependiendo de lo que el proveedor haya habilitado. Las complicaciones surgen a partir del octavo proveedor: cada suscripción requiere una configuración individual que suele quedar en la bandeja de entrada de una sola persona, cada proveedor formatea sus mensajes de forma distinta y filtrar solo los componentes que usted utiliza no siempre es posible. Algunos proveedores incluso mantienen una página interna sin botón de suscripción.
Un monitor de cambios web le proporciona un método homogéneo para cada proveedor: pega la URL de la página de estado, describe en una frase lo que le interesa y cada alerta llega al mismo canal con la misma estructura.
¿Qué páginas debería vigilar?
Elija la página que muestra el estado en tiempo real, normalmente status.proveedor.com. No seleccione la página de inicio corporativa ni su página de marketing sobre fiabilidad. La mayoría de páginas de estado de SaaS comparten la misma estructura: una lista de componentes con un indicador de estado, un banner para incidentes activos, las ventanas de mantenimiento programado y un historial breve de incidentes recientes con enlace al historial completo.
Empiece por las dependencias cuyo fallo percibirían primero sus clientes. Para la mayoría de los equipos de desarrollo, la lista es corta.
| Dependencia | Qué notan sus clientes cuando se cae |
|---|---|
| Pagos | Los pagos fallan o las renovaciones no se procesan |
| Inicio de sesión e identidad | Nadie puede acceder a la cuenta |
| Envío de email y SMS | Los correos de restablecimiento e invitaciones nunca llegan |
| Región cloud, CDN o DNS | Todo se vuelve lento o inaccesible |
| API de modelos de IA | Las funciones de IA agotan el tiempo de espera o dan error |
Si solo puede monitorizar unas pocas, empiece por las primeras. Los fallos en pagos y autenticación se traducen en tickets de soporte en cuestión de minutos, mientras que un CDN ralentizado tal vez solo se aprecie en sus métricas. Las 10 URL del plan gratuito cubren estas cinco filas y dejan espacio para las opciones adicionales que detallamos abajo.
Conviene tener presentes otras dos páginas. La página de historial (a menudo /history) es una excelente segunda vigilancia para un proveedor crítico: un incidente breve puede comenzar y resolverse entre dos comprobaciones de la página principal, pero quedará registrado en el historial, lo que le permitirá enterarse a posteriori. Durante una incidencia prolongada, también puede añadir la URL del incidente individual como monitor temporal para recibir cada actualización. Elimínelo cuando se resuelva para no saturar su límite de URL.
Configuración paso a paso
El proceso lleva unos cinco minutos y sigue el mismo flujo que nuestra guía de monitorización de changelogs, adaptando el brief.
1. Cree una cuenta y configure un canal
Regístrese gratis, vaya a Canales y añada el destino de las alertas. Le recomiendo crear un canal específico como #vendor-status en vez de publicar en #engineering, donde los mensajes se perderían. Slack, Discord y Microsoft Teams aceptan una URL de webhook entrante. En Teams, haga clic derecho en el canal, elija Conectores, luego Webhook entrante, Configurar y pegue la URL en Page Deltas. Para el email, el destinatario debe confirmar primero un mensaje de verificación. Pulse Enviar prueba en cada canal para validar la recepción.
2. Añada un monitor con un brief
Haga clic en Nuevo monitor y pegue la URL de la página de estado. Mantenga un proveedor por monitor para que cada brief pueda detallar los componentes exactos de ese proveedor, y si diferentes equipos supervisan distintos servicios, vincule un canal diferente a cada monitor.
Las páginas de estado cambian más a menudo de lo que parece, incluso en días tranquilos: los porcentajes de disponibilidad varían, las marcas de «última actualización» avanzan y la lista de incidencias recientes se desplaza cada día con una nueva fila de «No se han registrado incidencias». Los mantenimientos programados se anuncian con semanas de antelación. Una herramienta de diff visual básica dispararía alertas por todo ello.
La descripción del monitor es el prompt que nuestro LLM analiza para determinar si una variación es relevante. Escríbala como una nota para un compañero que estuviera revisando la página por usted. Para un proveedor de email, algo así resulta óptimo:
Página de estado de nuestro proveedor de correo. Solo usamos los componentes
Email API y Webhooks en la región US.
Avísame cuando se publique un nuevo incidente que afecte a esos componentes
o a esa región, cuando cambie su estado o gravedad, o cuando se resuelva.
Avísame si alguno de los dos componentes deja de estar en estado Operational.
Ignora porcentajes de uptime, marcas de tiempo de «última actualización»,
las filas diarias de «No se han registrado incidentes» y problemas en otras regiones.
Menciona el mantenimiento programado solo si comienza en menos de 48 horas.
Resume el componente afectado, el estado actual y la última actualización.La instrucción de exclusión realiza la mayor parte del trabajo. Si la omite, pasará su primera semana recibiendo avisos cada medianoche cuando la lista de incidentes avance un día.
En el caso de un gran proveedor de nube, los nombres de región y servicio son todavía más importantes. Un panel de nube pública abarca cientos de servicios en decenas de regiones, y en una semana normal siempre hay algo degradado en algún lugar. Nombre expresamente las regiones y servicios donde opera su infraestructura y solicite enterarse solo de ellos.
3. Deje que la primera comprobación fije la línea base
Un nuevo monitor realiza su primera revisión poco después de crearse. Esa revisión guarda el punto de partida inicial, por lo que no recibirá ninguna alerta en el primer minuto a menos que la página cambie entre dos revisiones. Acceda al monitor después y examine la captura para confirmar que registró la lista de componentes esperada.
4. Compruebe al instante ante cualquier sospecha
En Page Deltas no se configura un intervalo fijo. La programación es adaptativa: las páginas activas se revisan más a menudo y los planes de pago tienen prioridad si la cola se satura. Como una página de estado suele estar tranquila, si su tasa de errores sube y sospecha de un proveedor, pulse Comprobar ahora en su monitor. La misma acción está disponible vía API, con un límite de una vez por minuto por monitor:
curl -X POST \
-H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-nowQué hacer cuando llega una alerta
Cuando un cambio coincide con su brief, recibe un mensaje con un resumen en lenguaje claro y capturas de pantalla del antes y el después. Si utiliza el webhook firmado, el cuerpo del mensaje tiene esta estructura (los valores son simulados a modo de ejemplo):
{
"event": "change.detected",
"monitor_id": "01HX7Q...",
"monitor_url": "https://status.example-mail.com/",
"monitor_name": "Estado del proveedor de email",
"change_id": "...",
"detected_at": "2026-10-14T07:21:00Z",
"summary": "Nuevo incidente: retraso en entrega de emails en región US. Email API cambió de Operational a Degraded Performance. Estado: Investigando.",
"before_screenshot_url": "https://.../before.png",
"after_screenshot_url": "https://.../after.png",
"dashboard_url": "https://app.pagedeltas.com/monitors/..."
}La primera persona que vea la alerta debería responder en el hilo explicando el impacto previsto. Soporte puede fijar una respuesta de incidente conocido antes de que los tickets se acumulen. El ingeniero de guardia puede descartar revisar un despliegue que no causó los errores, y si la caída afecta a los usuarios, actualice su propia página de estado para que los clientes se enteren primero por usted.
Si su equipo trabaja con PagerDuty u otra herramienta de gestión de incidencias, el webhook firmado puede enviar los datos a través de una pequeña función intermedia. Como nuestro formato difiere del nativo de PagerDuty, unas pocas líneas de código serverless bastan para validar la firma y reenviar el evento:
import crypto from "node:crypto";
export async function handle(rawBody, signature) {
const expected = "sha256=" + crypto
.createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
.update(rawBody).digest("hex");
if (signature.length !== expected.length ||
!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
return 401;
}
const alert = JSON.parse(rawBody);
await fetch("https://events.pagerduty.com/v2/enqueue", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
routing_key: process.env.PAGERDUTY_ROUTING_KEY,
event_action: "trigger",
dedup_key: alert.change_id,
payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
}),
});
return 200;
}Calcule el hash sobre el cuerpo en crudo antes de analizarlo como JSON, o la firma no coincidirá. La documentación de canales cubre todos los detalles. Cada alerta se envía una única vez por canal sin reintentos automáticos: para proveedores indispensables, configure un segundo canal de otro tipo (Slack combinado con email, por ejemplo) en caso de que Slack o el intermediario fallen.
Dónde se detiene esta solución
Este método le transmite lo que el proveedor publica de forma oficial, y eso conlleva ciertas limitaciones que conviene conocer de antemano.
Los proveedores a menudo tardan en reconocer las incidencias. Sus propias gráficas de error mostrarán problemas en ocasiones antes de que la página de estado admita nada, así que tome la alerta como confirmación y no necesariamente como su primer indicio. Tampoco sustituye las pruebas sintéticas ni la monitorización de disponibilidad de su propia API. Estas últimas le advierten de que su servicio falla; la página de estado le ayuda a entender por qué.
Entre revisiones, los cambios se capturan en la siguiente ejecución programada, sin un intervalo fijo garantizado. Para los dos o tres proveedores donde cada minuto resulte crucial, conserve también la suscripción propia del proveedor y use Page Deltas para el resto. Asimismo, solo accedemos a páginas públicas, por lo que un estado visible únicamente dentro de una consola privada de administración queda fuera de alcance.
Comparamos el contenido textual de cada página. Si un proveedor refleja el estado exclusivamente con un indicador de color sin texto explicativo, no lo detectaremos. Visualping permite vigilar un área de píxeles concreta y se ajusta mejor a ese escenario. Por último, si la propia página de estado se cae, las revisiones fallan en lugar de alertar, y tras 10 fallos consecutivos el monitor se pausa automáticamente notificando a sus administradores.
Comience con tres proveedores
Elija los tres proveedores cuya caída le perjudicaría más, probablemente pagos, inicio de sesión y correo. Pegue las URL de sus páginas de estado, adapte el brief anterior indicando sus componentes y regiones, y envíe una alerta de prueba a #vendor-status. El plan gratuito incluye 10 URL con filtrado por IA, todos los canales de alerta y acceso a la API, sin requerir tarjeta de crédito. Empezar a monitorizar gratis.
Julien, gestor de producto en Page Deltas