Traducción automáticaEsta página se tradujo automáticamente. El original en inglés es la versión de referencia.Leer esta página en inglés

Estado del sistema

La página de estado de Disband es autohostada. No depende de un servicio de estado de terceros, por lo que aún puede informar con precisión cuando el alojador web principal, API, o la entrega de activos estáticos tengan problemas.

Lo que muestra la página pública

La página de grupos de monitores por servicio muestra, para cada monitor:

Debajo de los monitores se encuentran incidentes, mantenimiento programado y anuncios. Cada uno abre una página de detalles con la cronología completa de la actualización. El feed publica los últimos 25 incidentes, ventanas de mantenimiento y anuncios publicados como RSS 2.0.

Cheques

Una función Supabase Edge llamada status-probe se ejecuta cada minuto bajo pg_cron. Probará cada monitor habilitado en paralelo y registrará una fila por comprobación.

Cada monitor tiene:

Contexto Significado
Nombre La etiqueta pública, por ejemplo Sitio web.
Grupo La sección bajo la que aparece, por ejemplo Disband.
URL El http o https URL absoluto para solicitar.
Método GET o HEAD. Por defecto es GET.
Estado esperado El estado exacto de HTTP que cuenta como saludable. Por defecto es 200.
Palabra clave Texto opcional que debe aparecer en el cuerpo de la respuesta.
Tiempo de espera 1-30 segundos. Por defecto es de 10 segundos.
Cabeceras Cabeceras de solicitud opcionales, almacenadas en el lado del servidor.
Activado Ya sea que la sonda lo solicite o no.
Público Ya sea que contribuya a la instantánea pública.

Un monitor es saludable solo cuando el código de estado coincide y la palabra clave opcional está presente. Se siguen las redirecciones. Se registra un tiempo de espera excedido, un error de red, un estado incorrecto o la ausencia de la palabra clave como una comprobación fallida con la razón.

La sonda funciona de forma independiente de la aplicación web. Un fallo en el servidor web no detiene la grabación de las comprobaciones.

Historia y tiempo de actividad

Cada cheque se almacena en status_checks. Un desencadenante de base de datos dobla cada cheque en status_daily, por lo que la barra de 90 días es una lectura barata en lugar de una agregación sobre millones de filas.

Una brecha, un día sin cheques, se muestra como sin datos, no como tiempo de inactividad.

Incidentes automáticos

La sonda abre un incidente automáticamente cuando un monitor ha fallado tres comprobaciones seguidas. El incidente es un incidente grave, vinculado a ese monitor, y comienza en Investigando con una actualización automatizada que contiene el último error.

Cuando el siguiente cheque tenga éxito, el incidente se mueve a Resuelto y una actualización registra aproximadamente cuánto tiempo duró la interrupción. El incidente permanece en la página y en el feed con su historial completo.

Si un servicio está funcionando pero no falla tres veces consecutivas, no se abre ningún incidente automático. El propietario aún puede agregar una actualización manual a un incidente automático mientras este está abierto.

Incidentes manuales, mantenimiento y anuncios

El propietario puede publicar tres tipos de entrada:

Tipo Uso para
incident Un problema no planeado.
maintenance Trabajo planificado, opcionalmente con un inicio y un final de tiempo.
announcement Un aviso general de servicio que no es una interrupción.

Un incidente puede afectar a uno, varios o todos los monitores. Su impacto es uno de none, minor, major o critical.

Los estados de actualización son:

Cada actualización agrega una entrada con fecha y hora a la línea de tiempo del incidente y establece el estado actual del incidente. Marcar una actualización resolved o completed también establece el tiempo resuelto. Publicar una actualización posterior con otro estado la reabre.

Estado general

El banner se decide en este orden:

  1. Una ventana de mantenimiento activo dice Mantenimiento en progreso, o Mantenimiento programado antes de que comience.
  2. Un incidente crítico o importante activo dice Cierre importante.
  3. Un incidente menor activo dice Parcialmente degradado.
  4. Los monitores fallidos dicen Parcialmente degradado o Cierre importante cuando cada El monitor público está fallando.
  5. Sin fallos y al menos con un resultado, dice Todos los sistemas operativos.
  6. Antes de que lleguen los primeros cheques, dice Esperando los primeros cheques.

Los incidentes resueltos no afectan al banner.

intimidad

El camino de lectura público es una función de base de datos, no un acceso directo a la tabla. Devuelve nombres de monitores, grupos, estados, latencia, tiempo de actividad y incidentes. Omite deliberadamente:

Las tablas básicas tienen la seguridad a nivel de fila habilitada sin políticas públicas. Solo el rol de servicio y la función de sondeo pueden leerlas directamente.

administración

/status/admin está restringido al propietario de la plataforma que haya iniciado sesión. No es un rol de espacio y no se puede conceder a otro miembro. Las solicitudes no autenticadas reciben 401; otras cuentas iniciadas sesión reciben 403.

La pantalla de administración puede:

Administrador API

La pantalla utiliza estas rutas solo para los propietarios:

Método Punto final
GET, POST /api/status-admin/monitors
PATCH, DELETE /api/status-admin/monitors/{id}
GET, POST /api/status-admin/incidents
PATCH, DELETE /api/status-admin/incidents/{id}
POST /api/status-admin/incidents/{id}/updates

Aceptan el token de acceso de Supabase del propietario como Authorization: Bearer <token>. Son detalles de implementación de la pantalla de administrador, no una API público; la forma puede cambiar.

Notas operativas

relacionado