> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bbrands.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Monitoreo y páginas de estado
> Cómo B Brands observa cada plataforma: una única capa de monitoreo Better Stack, tres entornos, páginas de estado públicas impulsadas por la salud real de producción.
Esta sección documenta la **plataforma de monitoreo de B Brands** — la única capa
que observa cada app e integración a través de `development`, `certification`
y `production`, publica una página de estado pública por entorno, y está
definida enteramente como código (Terraform) y operada a través de GitHub Actions.
## Qué es esto
Cada entorno tiene su propio workspace de **Better Stack** con una página de estado
pública. En lugar de que un humano decida si un componente está sano, el estado se
deriva del **tráfico real de producción** que fluye a través de `horizon-api`: la API
computa un veredicto de salud por componente, Better Stack lo consulta, y la página
de estado refleja la realidad automáticamente.
Se usan dos productos independientes de Better Stack:
Páginas de estado, monitores HTTP y heartbeats de cron. Impulsa el estado verde / amarillo /
rojo que ve cada visitante.
Fuentes de logs, métricas y alertas basadas en logs. Alimenta los gráficos de infraestructura y
las alertas (opcionales) de tasa de error por servicio.
## Los tres entornos
Cada entorno está totalmente aislado: su propia página de estado, sus propios monitores, su
propio host de API y sus propios tokens. Nada se comparte entre entornos.
| Entorno | Página de estado | Host de Horizon API |
| ------------- | --------------------------------- | ------------------------------ |
| Development | `development.status.bbrands.io` | `development.api.bbrands.io` |
| Certification | `certification.status.bbrands.io` | `certification.api.bbrands.io` |
| Production | `status.bbrands.io` | `api.bbrands.io` |
## Qué significa cada color
La página de estado habla a dos audiencias a la vez — el negocio (¿es utilizable la plataforma?)
y la ingeniería (¿qué está fallando exactamente?).
El componente atiende el tráfico normalmente. La tasa de error está dentro de la banda
saludable.
El componente aún responde pero se detectó una tasa de error sostenida, una ruta que falla o
un cron obsoleto. Los usuarios pueden notar lentitud o fallos parciales.
Una caída real: la tasa de error de ventana corta cruzó el umbral de caída. El
endpoint del componente devuelve `503`.
## Qué se monitorea
Cada entorno converge al mismo catálogo, cada uno apuntando a sus propios
hosts.
10 apps frontend + 11 categorías de API + 9 integraciones. Better Stack consulta
cada una cada 1-3 minutos.
Health API, Health Integrations y Metrics Push. Confirman que el scheduler
en sí sigue funcionando.
Plataformas, API, Integraciones e Infraestructura — cómo se agrupan los componentes
para los visitantes.
Una fuente de logs/métricas por entorno para los gráficos de infraestructura y las alertas de
logs.
## Cómo fluye la señal
```mermaid theme={null}
flowchart LR
subgraph app [horizon-api]
traffic["Real traffic
recordApiTraffic"]
verdict["Tri-state verdict
operational / degraded / down"]
endpoint["GET /health/component/..."]
crons["Health & metrics crons"]
end
subgraph bs [Better Stack]
monitors["30 HTTP monitors"]
reports["Status Reports API"]
heartbeats["3 cron heartbeats"]
telemetry["Telemetry source"]
page["Status page"]
end
traffic --> verdict --> endpoint
monitors -->|"pull every 1-3 min"| endpoint
crons -->|"push create/resolve"| reports
crons -->|"self-heartbeat"| heartbeats
crons -->|"push latency metrics"| telemetry
monitors --> page
reports --> page
```
## La regla de oro: los monitores deciden el rojo, los Status Reports deciden el amarillo
Este es el concepto más importante de toda la plataforma. Las dos
capas de salud son deliberadamente independientes para que un problema del scheduler nunca
pueda fingir una caída.
Un monitor consulta el endpoint del componente. Solo ve `503` cuando la
tasa de error de ventana corta es una caída real. Esta ruta **no depende
del scheduler de crons**, así que un tick perdido no puede producir un falso rojo.
Los crons de salud comparan cada veredicto con el estado publicado y
crean/resuelven Status Reports. Un tick perdido solo **retrasa** la transición al
amarillo, lo cual es inofensivo.
## Adónde ir después
Cómo se computa y publica el veredicto de tres estados.
La definición Terraform de cada recurso de Better Stack, y `plan` vs
`apply`.
El workflow de GitHub Actions que valida y aplica los cambios de forma segura.
Tareas del día 2: sincronizar variables de entorno, agregar un monitor, rotar tokens, resolver drift.