Postmortems incidentes
Cada incidente > 5 minutos downtime termina con un postmortem público. Timeline · causa raíz · acciones correctivas. Cultura blameless desde el día 0 · pre-revenue · sin contratos NDA que ocultar.
Principios postmortem
Inspirados en Google SRE Book + Stripe engineering culture + Linear incident response. Aplicados desde el primer incidente · documentados en doctrine repo público.
Archivo postmortems
3 incidentes documentadosTodos los incidentes pre-revenue 2026 listados abajo. Cuando llegue tráfico real, mantendremos archivo cronológico inverso (más reciente arriba) sin borrar histórico.
Cold-start Cloudflare Worker tras deploy v1.12.0
Impacto: 0 clínicas reales (pre-revenue) · 2 demo internas
Tras deploy v1.12.0, Worker cold-start tardó 13 minutos en estabilizarse por nueva dependency (zod v4 schema parse en startup). Health endpoint respondió 504 durante ese tiempo.
- 16:32 UTC · wrangler deploy v1.12.0 ejecutado
- 16:32 UTC · UptimeRobot detecta 504 health endpoint
- 16:33 UTC · Sentry alerta + email founder + Slack
- 16:34 UTC · Founder valida deploy nuevo · monitoriza
- 16:45 UTC · Worker estabilizado · 2 polls consecutivos verdes
- 16:48 UTC · Postmortem iniciado
- Mover zod schema parse de startup a primera request (lazy init)
- Añadir warmup ping post-deploy en CI/CD (3 requests sintéticos)
- Documentar cold-start expected window en runbook deploys
Meta WhatsApp token expirado · 32min downtime mensajería
Impacto: 1 demo clínica interna · 0 producción real
Meta permanent token rotó silenciosamente tras Meta Business Verification expirar. Sistema no detectó hasta primer envío fallido. Sin cron de health-check pre-emptive del token.
- 11:14 UTC · Primer envío WhatsApp test devuelve 401 Meta API
- 11:14 UTC · Sentry captura error · alerta inmediata
- 11:18 UTC · Founder reproduce · identifica token issue
- 11:25 UTC · Rotación manual token Meta Business Manager
- 11:38 UTC · wrangler secret put META_TOKEN · deploy
- 11:46 UTC · Test envío verde · servicio restaurado
- Cron diario meta-token-healthcheck (alerta 7d antes expiración)
- Documentar runbook rotación Meta token paso a paso
- Issue tracking calendar Meta Business Verification renewal
- ADR-027 actualizado · breaker Meta opt-in para limit blast radius
QStash retry loop bug · 15min queue backup
Impacto: 1 demo clínica · 0 producción real
Bug en handler outbound-message · response 500 sin signal de no-retry. QStash interpretó como retriable · 4 retries × 12 mensajes = 48 jobs en queue. Backup visible 15min hasta drainage.
- 09:48 UTC · Deploy contiene bug handler outbound-message
- 09:50 UTC · Primer error 500 capturado Sentry
- 09:52 UTC · QStash inicia retries (backoff 30s)
- 09:58 UTC · Founder detecta backlog en Upstash dashboard
- 10:01 UTC · Hotfix deploy con response 422 explícito
- 10:03 UTC · Queue drainage completa
- Standard responses pattern · 422 explícito en validation errors
- QStash dead-letter queue (DLQ) monitorizado en /status
- Test integration QStash retry behavior añadido
- ADR-008 actualizado · 422 vs 500 retry semantics
Cómo escribimos un postmortem
- Detección · timestamp exacto primer signal + canal (UptimeRobot · Sentry · cliente report)
- Triage · severity asignada (P0 todo down · P1 parcial · P2 cosmético)
- Mitigación · cómo se restauró servicio (rollback · hotfix · workaround)
- Causa raíz · 5 Whys hasta encontrar gap sistémico (no humano)
- Acciones correctivas · 3-5 mejoras concretas con owner + deadline
- Publicación · esta página actualizada <48h tras incidente resuelto
Slash command interno · `/incident-rca` automatiza este flow · referenciado en `.claude/commands/incident-rca.md` repo público.
¿Buscas evidencia operacional pre-Enterprise?
Si tu compliance officer quiere ver cómo gestionamos incidentes antes de firmar, esta página es el evidence pack. Si necesitas RCA específico de algún incidente o quieres revisar runbooks internos, lo compartimos bajo NDA.