Mi aplicación web se cayó: plan de respuesta a incidentes
Publicado el 2026-11-14 por frfrand
Guía operativa para contener, diagnosticar, recuperar y comunicar una caída de aplicación con un equipo pequeño.
# Mi aplicación web se cayó: plan de respuesta a incidentes
Cuando una aplicación deja de responder, el orden de las decisiones importa. Reiniciar procesos repetidamente puede borrar evidencias, empeorar un problema de datos o ocultar su causa. Una respuesta eficaz combina diagnóstico rápido, contención, recuperación y comunicación.
1. Confirma el alcance
Reproduce el fallo desde redes distintas. Pregunta: ¿afecta todas las rutas o solo una? ¿Frontend, API, base de datos, DNS, certificado TLS o proveedor externo? ¿La caída comenzó tras un deploy? Registra hora en UTC, síntomas, cambios recientes y personas responsables.
Comprobaciones iniciales orientativas:
curl -I https://ejemplo.com
dig ejemplo.com
systemctl --failed
df -h
free -h2. Clasifica y contiene
Define gravedad por impacto: pérdida de datos, fallo total de servicio, degradación parcial o defecto visual. Ante indicios de intrusión, preserva logs y evidencia antes de limpiar o reiniciar; aísla credenciales comprometidas y considera asesoramiento especializado. Si se trata de despliegue defectuoso, evita seguir desplegando sin resolver la causa.
3. Diagnostica por capas
| Capa | Indicador | Acción segura | | --- | --- | --- | | DNS/TLS | Dominio no resuelve o cert caducado | Revisar resolución y certificado | | Reverse proxy | 502/504 | Revisar upstream y tiempos | | Aplicación | 500 o crashes | Inspeccionar logs y cambios | | Base de datos | Conexiones agotadas o consultas lentas | Medir pool, locks y disponibilidad | | Sistema | Disco/CPU/RAM saturados | Medir consumo y proceso responsable | | Terceros | API externa con fallos | Activar degradación o reintentos limitados |
Consulta journalctl -u servicio --since "30 minutes ago" si usas systemd, respetando privacidad de logs. Revisa Nginx y métricas antes de aumentar recursos a ciegas.
4. Restaura con un plan reversible
Si el último release causó el fallo, considera rollback de aplicación solo cuando el esquema y los datos lo permitan. No reviertas una base de datos con escrituras nuevas sin analizar pérdida. Si se necesita recuperación desde backup, verifica un punto de restauración fiable y acuerda posible pérdida de datos con el responsable.
5. Comunica sin inventar plazos
Emite un mensaje breve con funciones afectadas, acciones en curso, alternativa temporal y hora del próximo parte. No atribuyas causa sin evidencia. Mantén un registro de decisiones y responsables. Para clientes, distingue tiempo de respuesta de tiempo de resolución.
6. Postmortem y prevención
Después de recuperar, identifica la causa técnica y los factores organizativos. Incluye línea de tiempo, detección, impacto, acción de mitigación y tareas preventivas con responsable. Añade health checks de negocio, alertas, backups probados y despliegues reversibles.
Relacionados: diagnóstico DNS y cron vs systemd timers.
Preguntas frecuentes
¿Reiniciar siempre es lo primero? No; depende del riesgo de perder evidencia y datos. ¿Qué significa 502? El proxy no obtuvo una respuesta válida de upstream. ¿Cuándo informar al cliente? Temprano, con hechos confirmados y actualizaciones acordadas.