Qué datos guardar después de una caída de la web

Después de una caída, la tentación es cerrar la incidencia en cuanto vuelve la portada. Sin datos, el mismo fallo puede repetirse y será más difícil reconstruir qué ocurrió. Guarda una cronología y las señales mínimas mientras todavía existen en logs y paneles. Protege credenciales y datos personales: un informe técnico útil no necesita copiar pedidos completos ni contraseñas.

Documenta el impacto antes de explicarlo

Registra inicio, detección, recuperación y zona horaria. Anota qué servicios fallaron: web pública, panel, formulario, correo, API, carrito o checkout. Separa clientes afectados confirmados de estimaciones. Si hubo pagos, compara identificadores de pasarela con pedidos sin reintentar cargos a ciegas. Conserva capturas propias del error y códigos HTTP, indicando URL y hora; una captura sin contexto puede resultar engañosa.

Conserva métricas y cambios relevantes

• Registros de acceso/error del servidor y de aplicación alrededor del incidente, con tratamiento de IP y datos según política.
• CPU, memoria, disco, procesos, base de datos y latencia por ruta; anota si el panel dejó de medir durante la caída.
• Cambios de despliegue, PHP, plugins, DNS, certificado, WAF, CDN y proveedor externo cercanos a la hora inicial.
• Alertas recibidas, acciones ejecutadas, quién las autorizó y resultado observado.

La guía de logs ayuda a leer las entradas; el análisis de picos distingue solicitud, proceso y servicio externo. No declares «falló el hosting» solo porque el navegador mostró 503; relaciona el código con el registro de origen y los recursos.

Redacta una causa comprobable y una acción preventiva

Divide el informe en síntoma, evidencia, hipótesis, prueba y conclusión. Puede quedar una causa sin confirmar; indícalo en lugar de inventarla. Describe cómo se recuperó, qué verificación funcional se hizo y qué riesgo permanece. Para cada acción preventiva asigna responsable, fecha y forma de comprobar que funciona: por ejemplo, alerta de espacio libre probada o ensayo de restauración registrado.

Haz seguimiento

Revisa si el monitor detectó el fallo antes que los clientes y si las alertas llegaron al responsable disponible. Programa una prueba acotada del escenario, sin provocar otra caída. Si necesitas estudiar capacidad, consulta cómo ensayar concurrencia; si la causa fue una dependencia caducada, usa el inventario de vencimientos. Para soporte, envía un resumen con hora, URL, error y métricas saneadas, nunca accesos completos.

Convierte los datos en un registro de incidencia

Asigna un identificador, responsable y estado. Separa la cronología de hechos observados de hipótesis y decisiones. Registra cuándo se confirmó el impacto, a quién se avisó, qué cambio se aplicó, quién autorizó reversión y qué prueba cerró el incidente. Al analizarlo, distingue causa inmediata, factores que ampliaron el impacto y controles que no avisaron. Una caída sin causa demostrada puede cerrarse operativamente, pero deja una investigación pendiente con fecha. Comparte con clientes solo datos pertinentes y una explicación honesta; evita exponer IP, pedidos o detalles de seguridad. Relaciona la incidencia con alertas que necesitan mejora si afectó a ventas.