Para qué sirve realmente una status page
Durante una caída, los clientes no saben si es su conexión, su cuenta o tu servicio. Sin una status page, esa incertidumbre se convierte en tickets, tweets y mensajes repetidos justo cuando tu equipo está arreglando el problema.
Una status page absorbe eso. Un enlace, un lugar para mirar, actualizado mientras ocurre el incidente. No arregla la caída, pero elimina el segundo problema: clientes confundidos.
Qué debe incluir
Como mínimo, los componentes que importan a clientes: sitio o app principal, API si otros la integran y cualquier parte con un modo de fallo propio. Cada componente debería mostrar estado actual y una cifra de uptime reciente.
Además, las actualizaciones de incidente convierten la página en un canal real: una nota cuando algo se rompe, otra cuando sabes más y una resolución al arreglarlo. Un badge de uptime embebible ayuda a que la página sea visible desde README o docs.
Por qué debe depender de monitores reales, no actualizarse a mano
Una status page que alguien tiene que cambiar manualmente a rojo durante un incidente tiene un fallo obvio: depende de que una persona lo note y lo recuerde justo cuando está más ocupada. También suele quedarse en “todo operativo” después de que algo se rompió.
Conectada a los mismos monitores que ya vigilan el sitio, la status page se actualiza cuando falla un check y vuelve a verde al recuperarse, sin pasos manuales en el momento más crítico.
Errores que vuelven inútil una status page
Mantenimiento manual y datos viejos. Si va horas detrás de la realidad, los clientes dejan de confiar en ella y vuelven a abrir tickets.
Sin historial de incidentes. Una página que solo muestra el estado actual no responde “qué tan fiable ha sido esto”, que a menudo es la pregunta real de un cliente potencial.
Escondida donde nadie la encuentra durante una caída. Si no está enlazada desde producto, docs o footer, no ayuda cuando hace falta.
Cómo escribir buenas actualizaciones de incidente
La parte automática de una status page dice que algo cambió; no explica qué pasó ni qué esperar. Una nota breve como “somos conscientes de un problema en [componente] y lo investigamos” vale más que el silencio; una segunda actualización y una nota de resolución suelen bastar.
La tranquilidad vaga sin hora ni siguiente paso es poco mejor que nada si no se actualiza. El nivel mínimo es publicar rápido y hacer seguimiento.
Status pages públicas frente a internas
Una status page pública es para clientes y personas que integran tu API: debe ser simple, precisa y no filtrar detalles internos. Una interna puede tener más componentes y más detalle porque el equipo conoce los sistemas. Muchos equipos terminan queriendo ambas.
Cómo lo hace Holter
Las status pages de Holter dependen de los mismos monitores que revisan tu sitio: un componente se pone rojo porque falló un check real y vuelve a verde porque se recuperó, sin paso manual. Incluyen historial de uptime, notas de incidente y badge embebible; cada página empieza en el plan Free junto a 5 monitores y checks cada 5 minutos, sin tarjeta.
Holter vigila esto por ti: monitores externos y heartbeats para fallos silenciosos. Plan gratis: 5 monitores, comprobaciones cada 5 minutos, sin tarjeta.
Crear una status page gratis