3:17 AM. El teléfono vibra. El monitor de uptime — un servicio que hace ping a tu sitio cada pocos minutos y te avisa cuando deja de responder — dice que tu app está muerta. No hay equipo. No hay rotación de guardia. No hay SRE (site reliability engineer, la persona cuyo trabajo completo es mantener los servicios vivos). Solo tú, tu laptop y la adrenalina.

Esto no es hipotético. El 1 de marzo, AWS sufrió una falla en cascada que empezó en la región de UAE y se extendió por US-EAST-1, tumbando 38 servicios y dejando a founders solos mirando dashboards de errores sin nadie a quién llamar. Después, el 27 de marzo, Cloudflare Pages rompió la gestión de dominios personalizados durante horas — lo que significa que founders que habían desplegado sus sitios de marketing en Pages vieron sus dominios desaparecer de internet en plena jornada laboral.

Yo he estado ahí. Más veces de las que un capibara debería admitir. Las primeras veces entré en pánico y empeoré todo. Ahora tengo un playbook. Elimina el pánico de la ecuación y lo reemplaza con pasos. Aquí está completo. 📋

Paso 0: No arregles nada todavía

Contraintuitivo. Tu app está caída. Cada segundo cuesta dinero, reputación, o ambos. Tu instinto grita: arréglalo ya.

Pero lo más peligroso que puedes hacer durante un incidente es actuar sin entender qué se rompió.

He visto founders solos conectarse por SSH — acceder remotamente a su servidor mediante una terminal segura — a producción a las 3 AM, ejecutar un comando de memoria y tumbar la base de datos junto con la app. Un problema se convirtió en dos. El fix original tomaba 20 minutos. La recuperación de la base de datos tomó 6 horas.

Regla cero: antes de tocar cualquier cosa, dedica 2 minutos a entender la situación. No 20 minutos. Dos. Lee el error. Revisa los logs. Formula una hipótesis. Después actúa.

Paso 1: Triage — 2 minutos

Hazte tres preguntas:

¿El servicio está completamente caído o parcialmente degradado? Consulta tu health endpoint — una URL especial que reporta si los sistemas centrales de tu app están funcionando, como un chequeo de pulso integrado. Si la app carga pero las llamadas API (peticiones de tu frontend a tu backend) fallan, eso es parcial. Si no carga nada, es total. Esto determina la urgencia.

¿Los usuarios están afectados en este momento? Revisa tus analytics. Si son las 3 AM en tu zona horaria y tus usuarios están en la misma zona, quizás cinco personas se dieron cuenta. Si tus usuarios son globales, cientos podrían estar viendo una página de error ahora mismo.

¿Cuándo empezó? Revisa tu dashboard de monitoreo. Si se rompió hace 5 minutos, probablemente está relacionado con lo último que cambió. Si el servicio lleva 3 horas tambaleándose y apenas te llegó la alerta, tu monitoreo tiene un hueco que necesitas arreglar mañana.

Anota las respuestas. Una libreta, un mensaje a ti mismo, un archivo de texto. Esto se convierte en tu incident log — el documento único que registra todo sobre esta caída. Te lo vas a agradecer en la mañana.

Paso 2: Comunica — 1 minuto

Aunque nadie esté despierto, publica una actualización de estado. Tu status page, tus redes sociales, tu Discord — donde sea que tus usuarios revisen. Una oración:

"Estamos al tanto de un problema que afecta [servicio]. Investigando. Actualizaremos en 30 minutos."

El silencio asusta más que una caída conocida. Los usuarios que ven "investigando" esperan con paciencia. Los usuarios que no ven nada asumen lo peor y empiezan a publicar al respecto. Un minuto de comunicación te compra 30 minutos de investigación tranquila. ⚙️

Paso 3: Revisa lo obvio — 5 minutos

El 80% de los incidentes en empresas pequeñas se reducen a una de cinco causas:

1. Disco lleno. Ejecuta df -h (muestra el espacio en disco en formato legible). Si algún sistema de archivos marca 100%, ahí está tu culpable. Fix rápido: encuentra y elimina archivos de log sobredimensionados. du -sh /var/log/* revela a los responsables.

2. Sin memoria. Ejecuta free -h (muestra el uso de RAM). Si la memoria disponible está cerca de cero, algo la está acaparando. ps aux --sort=-%mem | head -10 lista los mayores consumidores de memoria — el equivalente digital de encontrar quién dejó todas las luces prendidas. Mata el proceso inflado, reinicia el servicio.

3. Proceso crasheado. Ejecuta systemctl status tu-app — systemctl es el administrador de servicios de Linux, la herramienta que inicia, detiene y monitorea tus aplicaciones. Si dice "inactive (dead)" o "failed", reinícialo: systemctl restart tu-app. Después revisa por qué crasheó: journalctl -u tu-app --since "1 hour ago" (journalctl lee el diario de eventos del sistema).

4. Certificado SSL expirado. SSL (Secure Sockets Layer) es el candado en tu navegador — significa que la conexión está encriptada. Estos certificados expiran. Los certificados de Let's Encrypt duran 90 días. Si olvidaste la auto-renovación, este es un problema de las 3 AM esperando suceder. Fix: certbot renew && systemctl reload nginx. Configura la renovación automática de Certbot este fin de semana para que esto no vuelva a pasar.

5. Problema de DNS. DNS (Domain Name System) es la guía telefónica de internet — convierte "tusitio.com" en una dirección de servidor que las computadoras pueden encontrar. Ejecuta dig tusitio.com para verificar. Si no resuelve, tu proveedor de DNS podría tener problemas. O tu dominio expiró. Sí, los dominios expiran. Lo he visto pasar en startups con inversión.

Si ninguna de estas cinco coincide, estás en el 20% que necesita debugging real. Pasa al Paso 4.

Paso 4: La auditoría de cambios recientes — 5 minutos

Algo cambió. Los servicios no se rompen solos — como la plomería, fallan porque algo se movió. Pregúntate:

  • ¿Hice deploy de algo recientemente? Deploy significa subir código nuevo a tu servidor en vivo. Revisa git log --since="24 hours ago" para ver cambios recientes.
  • ¿Cambié alguna configuración? Revisa las fechas de modificación de tus archivos de config.
  • ¿Se actualizó alguna dependencia? Una dependencia es código de alguien más del que tu app depende — una librería, un framework. Revisa tu package lock file por cambios recientes.
  • ¿El proveedor de hosting tuvo un problema? Revisa su status page.

La respuesta más común: hiciste deploy de algo. El fix: rollback — volver a la versión anterior que funcionaba. No debuggear. Rollback. Que el servicio funcione, debuggea mañana.

# Si etiquetas tus releases (etiquetas de versión como v1.2.3):
git checkout v1.2.3
bash deploy.sh

# Si aún no etiquetas versiones (empieza a hacerlo hoy):
git revert HEAD
bash deploy.sh

Hacer rollback se siente como rendirse. No lo es. Es la respuesta más profesional que puedes dar: priorizar el uptime sobre el ego. Arregla el código mañana con café y luz del día. 🍵

Paso 5: La regla de los 30 minutos

Si no encontraste la causa raíz — la razón real por la que algo se rompió, no solo el síntoma — en 30 minutos, escala. "Pero soy founder solo. ¿Escalar a quién?"

  • El soporte de tu proveedor de hosting. Si pagas por hosting administrado, úsalo. Para eso es literalmente.
  • Un contractor en retainer. Incluso $200 dólares al mes por "te puedo escribir a las 3 AM dos veces al año" vale la pena.
  • Tu comunidad. Un servidor de Discord relevante, grupo de Slack o foro. Publica el error, tus logs, lo que intentaste. Las buenas comunidades responden rápido.
  • Un asistente de IA. Pega el error en Claude o ChatGPT: "Aquí está mi log de error del servidor. El servicio crasheó a las 3:17 AM. Esto es lo que revisé: [lista]. ¿Qué más debería revisar?" No va a conectarse por SSH a tu servidor, pero puede sugerirte pasos de diagnóstico que se te escaparon.

La regla de los 30 minutos existe porque después de media hora de debugging solo a las 3 AM, tu juicio se deteriora. Empiezas a probar cosas al azar. Cambios aleatorios en un servidor de producción en vivo a las 3 AM — así es como los datos desaparecen permanentemente.

Paso 6: La mañana post-incidente

Sobreviviste la crisis. Vuelve a dormir. En serio. El postmortem — el análisis estructurado de qué salió mal y cómo prevenirlo — es para mañana. Con café. Con la cabeza despejada. 🛁

Checklist de mañana:

  1. ¿Qué se rompió? Una oración.
  2. ¿Cuál fue la causa raíz? No "el servidor crasheó" sino "Una mala configuración de log rotation llenó el disco al 100%."
  3. ¿Cuál fue el impacto? Duración, usuarios afectados, ingreso perdido si es medible.
  4. ¿Qué impidió detectarlo más rápido? Arregla ese hueco de monitoreo.
  5. ¿Qué impidió recuperarte más rápido? Agrega ese paso a tu playbook.
  6. ¿Qué previene que esto pase de nuevo? Impleméntalo esta semana. No "algún día". Esta semana.

Escribe esto en un archivo. incidents/2026-03-27.md. Estás construyendo conocimiento institucional — un historial buscable de qué se rompió antes y qué lo arregló. Cuando el próximo incidente llegue, tu yo del pasado ya dejó notas.

La preparación pre-incidente

La mejor respuesta a incidentes ocurre antes del incidente. Esto es lo que debes configurar este fin de semana:

  • Monitoreo de uptime. UptimeRobot tiene un tier gratuito: 50 monitores, intervalos de 5 minutos. Hace ping a tu sitio y te avisa cuando se cae. Lo configuras una vez y te olvidas. ✅
  • Log rotation. Configura logrotate — una utilidad de Linux que automáticamente comprime y elimina archivos de log viejos — para cada log que tu app produce. Los discos no se llenan cuando los logs están gestionados.
  • Auto-renovación de SSL. Certbot con un cron job (una tarea programada que se ejecuta automáticamente en un temporizador). Nunca más renueves un certificado manualmente.
  • Backups automáticos. Dump de base de datos a S3 (el almacenamiento en la nube de Amazon) o cualquier object storage, cada 6 horas. Prueba el proceso de restauración al menos una vez. Un backup que nunca restauraste es una esperanza, no un backup.
  • Un script de rollback. Un comando para volver a la versión anterior. Sin pensar a las 3 AM.

Setup total: aproximadamente 3 horas en un sábado tranquilo por la tarde. Esas 3 horas protegen tu negocio la próxima vez que algo se rompa en la oscuridad.

Los founders más tranquilos que conozco no son tranquilos porque nada se rompe. Las cosas se rompen para todos. Son tranquilos porque tienen un playbook. Ya pasaron por esto antes. Saben qué hacer después. Y saben — profundamente, por experiencia — que el pánico nunca, ni una sola vez, arregló un servidor. 🫶

incident-response, devops, automation, solo-founder, infrastructure