Lo que ejecuto antes de dormir
Cada noche, antes de cerrar mi laptop, ejecuto un comando. Verifica 15.000 páginas en mi sitio en producción: cada entrada del blog, cada página de empresa, cada guía programática, cada variante de idioma. Para cada página, verifica el código HTTP, mide el TTFB, comprueba el estado de caché de Cloudflare y registra cualquier error. La verificación completa toma unas 6 horas. Se ejecuta en segundo plano mientras duermo.
También ejecuto una verificación rápida de rutas críticas que termina en 2 minutos: endpoints de salud, sitemaps, páginas de ingresos, hubs de empresas S-tier, páginas de mercado, índices de contenido programático, archivos de blog i18n. Esta la observo en tiempo real. Si algo falla, investigo antes de irme a dormir.
La rutina produce un reporte como este:
NIGHTCHECK -- 2026-03-27 (morning)
Overnight comprehensive: 16,228/16,602 ok (97.7%)
Avg TTFB: 715ms
S-tier companies: ALL PASS, ALL HIT
Markets: ALL PASS (89-175ms HIT)
i18n blogs: es 95ms HIT | ja 196ms HIT | de 181ms HIT
Nadie me pide que haga esto. Ningún ticket lo requiere. Ningún sprint incluye “ejecutar nightcheck”. La rutina existe porque me importa si el sitio funciona cuando no lo estoy mirando.
Por qué cada noche
El sitio cambia todos los días. En un solo día, puedo desplegar 87 commits: traducciones i18n, actualizaciones de proveedores de rastreo, experimentos de CRO, correcciones de rendimiento, remediaciones de logos. Cada commit se prueba individualmente, pero la composición de 87 commits puede producir fallos que ningún commit individual revela.
Un lote de traducciones podría llevar el sitemap del blog más allá de un umbral de renderizado. Un nuevo proveedor podría introducir una página de empresa que tarda 14 segundos en renderizar. Un cambio en los headers de caché podría hacer que Cloudflare deje de cachear una ruta que antes era rápida. Un refactor de CSS podría romper una plantilla en un idioma pero no en otros.
El nightcheck detecta fallos de composición. No “¿este commit rompió algo?”, sino “¿el sitio funciona después de que todo lo de hoy aterrizó?”. La distinción importa porque los fallos de composición son invisibles en CI. Cada commit pasa sus propias pruebas. El comportamiento agregado de 87 commits pasando sus propias pruebas no garantiza que el sistema agregado funcione.
Qué se mide
La verificación tiene cuatro niveles:
P0 Infraestructura. El endpoint de salud responde healthy con la base de datos conectada. Los sitemaps devuelven XML válido. Robots.txt y llms.txt están presentes. El feed RSS es válido. Son las cosas que, si se rompen, hacen el sitio invisible para los motores de búsqueda.
P0 Ingresos. La página principal, el constructor de currículum, el analizador y la página de precios cargan correctamente. Son las páginas que, si se rompen, cuestan dinero directamente. El constructor de currículum es históricamente la página más lenta y tiene un umbral de WARN en 5 segundos.
P1 Superficie SEO. Archivo del blog, páginas hub pilares, directorio de empresas, explorador de empleos, los cinco índices de contenido programático (guías de currículum, guías salariales, guías de carta de presentación, preguntas de entrevista, palabras clave ATS), cuatro muestras de blog i18n y los 20 hubs de empresas S-tier. Son las páginas que impulsan el tráfico orgánico. Un 404 en la página de Google es un incidente SEO.
P2 Integral. Cada URL en los sitemaps de blog y empresas. Esta es la verificación de fondo de 6 horas. Detecta los fallos de cola larga: una entrada de blog que devuelve 500 por una cita malformada, una página de empresa que agota el tiempo por una consulta N+1 en una empresa grande.
Cada página se verifica con curl usando un header User-Agent realista. Un curl sin configurar recibe 403 de Cloudflare. El header de estado de caché se captura junto con el código HTTP y el TTFB. Una página puede devolver 200 pero mostrar DYNAMIC cuando debería ser HIT, lo que significa que la regla de caché está mal configurada. La medición de TTFB es la latencia real del lado del servidor, no el tiempo de renderizado del navegador.
La tendencia del TTFB
He estado ejecutando esta verificación desde marzo de 2026. La tendencia del TTFB cuenta la historia del rendimiento:
| Date | Avg TTFB | Worst Page | Cache Status |
|---|---|---|---|
| Mar 21 (post-purge) | 1,156ms | Austin market 14,290ms | ALL DYNAMIC |
| Mar 23 (cache live) | 958ms | markets 2-3s | Most HIT |
| Mar 25 (query fix) | 715ms | ats-optimization 6.3s | All HIT |
| Mar 27 (stable) | 715ms | zh-hans/blog 3.7s | 34/36 HIT |
La tendencia captura el recorrido del rendimiento de las páginas de mercado: la purga de caché expuso el problema (14,3s), el caché en el borde lo enmascaró (89-175ms HIT), la corrección de la forma de la consulta resolvió la causa subyacente (108ms en origen). Sin la tendencia nocturna, habría creído que el caché en el borde era la solución. Las mediciones de TTFB demostraron que el renderizado en origen seguía siendo lento durante la revalidación, lo que justificó el refactor de la consulta.
El nightcheck no corrigió el problema de rendimiento. Hizo que el problema fuera medible, lo que lo hizo corregible.
Lo que nadie ve
Lo más valioso del nightcheck es que se ejecuta cuando nadie está mirando. No hay notificación de Slack que diga “16.228 páginas pasaron durante la noche”. No hay un dashboard que se ponga en verde. El reporte existe en un archivo de log que leo con el café de la mañana siguiente.
La ausencia de ceremonia es el punto. El nightcheck no es calidad performativa. No es una métrica para un standup. Es una disciplina privada: ¿todo funcionó mientras dormía? Si sí, bien. Si no, sé exactamente qué falló y cuándo.
La disciplina se acumula con el tiempo. La verificación de cada noche establece una línea base para la comparación del día siguiente. Un aumento de 50ms en el TTFB de una página específica desencadena una investigación, no porque 50ms importen al usuario, sino porque el aumento indica que algo cambió. Quizá una nueva dependencia añadió latencia. Quizá una regla de caché expiró. Quizá una consulta a la base de datos creció con el conjunto de datos. La línea base nocturna hace visible la degradación antes de que se convierta en un problema.
Esto es contexto compuesto aplicado a operaciones. La verificación de cada noche deposita un punto de datos. Los puntos de datos se acumulan en una tendencia. La tendencia hace visibles problemas que ninguna verificación individual revelaría.
La rutina es el estándar
Podría automatizar el nightcheck en un cron job y revisar un dashboard. Elijo ejecutarlo manualmente porque el acto de ejecutarlo mantiene el hábito de preocuparse. En el momento en que la verificación se convierte en el trabajo de alguien más, o en una notificación que descarto, o en un dashboard que dejo de revisar, el estándar se erosiona.
El estándar no es “el sitio pasa verificaciones automatizadas”. El estándar es “yo personalmente verifiqué que el sitio funciona antes de irme a dormir”. La diferencia es responsabilidad. Una verificación automatizada que falla en silencio es un bug en la automatización. Una verificación manual que me salto es una decisión que tomé sobre lo que me importa.
Lo ejecuto cada noche porque la alternativa es confiar en que todo sigue funcionando. Confianza sin verificación es esperanza. La esperanza no es una estrategia de operaciones.
FAQ
¿Cuánto tarda la verificación completa?
La verificación rápida de ruta crítica toma 2-3 minutos (36 páginas con medición de TTFB y caché). La verificación integral de sitemaps toma 5-7 horas (más de 15.000 páginas). La verificación rápida se ejecuta de forma sincrónica; la integral se ejecuta en segundo plano.
¿Por qué no usar un servicio de monitoreo de uptime?
Los servicios de uptime verifican si una página devuelve 200. El nightcheck verifica si una página devuelve 200 con el estado de caché correcto, un TTFB aceptable y la estructura de contenido esperada. Una página que devuelve 200 pero tarda 14 segundos con caché DYNAMIC está técnicamente activa y operativamente rota.
¿Qué pasa cuando algo falla?
Investigo antes de dormir si el fallo es en una página de ingresos o infraestructura. Para fallos en la verificación integral, reviso el log a la mañana siguiente y priorizo por tipo de página. Una entrada de blog que falla tiene menor prioridad que un hub de empresa que falla. Un caché DYNAMIC en una página de alto tráfico tiene mayor prioridad que un TTFB lento en una página de bajo tráfico.
¿Esto escala?
15.000 páginas es la escala actual. La verificación integral está limitada por I/O (solicitudes curl secuenciales), no por cómputo. Duplicar la cantidad de páginas duplica el tiempo de ejecución. Con 30.000 páginas, la verificación tomaría 12 horas, lo cual aún cabe en una ventana nocturna. Más allá de eso, sería necesaria la verificación en paralelo con limitación de tasa.