Best Practices3 February 20258 min readEspañol

El runbook on-call que cada equipo pequeño necesita

Un incidente a las 3 de la madrugada no es el momento para descubrir tu proceso.

Best PracticesUptime MonitoringWebsite MonitoringApi MonitoringCron Job Monitoring
Best Practices

No necesitas un equipo de 50 para tener un proceso sólido de respuesta a incidentes.

Qué es un runbook (y qué no es)

Un runbook no es una guía de solución de problemas para cada falla posible. Es una lista de verificación para los primeros 30 minutos de un incidente.

Marco de respuesta a incidentes de 5 pasos

1. Reconocer (0–2 min) — Reclamar el incidente. 2. Evaluar (2–5 min) — ¿Qué está realmente roto? 3. Comunicar (5 min) — Actualizar la página de estado. 4. Mitigar (5–30 min) — Llegar a un estado funcional. 5. Documentar (post-incidente) — Escribir un postmortem sin culpas.

Niveles de severidad para equipos pequeños

SEV1 — Producción caída. Despertar al on-call. SEV2 — Degradado. Manejar durante horas hábiles. SEV3 — Menor. Crear ticket.

A quién despertar y cuándo

- Ingeniero on-call: primer respondedor para todos los SEV1/SEV2 - Líder de ingeniería: escalar si no se resuelve en 30 minutos

Herramientas y comandos rápidos

git log --oneline -10 origin/main
docker compose restart api
This article is available across the supported locale routes — use the language switcher above to change.

Guía de producto

Uptime Monitoring

AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.

Leer guía

Página alternativa

Better Stack Alternative

Compare AlertsDock with Better Stack for teams that want a more focused monitoring product covering uptime, cron jobs, status pages, and webhooks.

Ver comparación
AD
AlertsDock Team
3 February 2025
Try AlertsDock free