Lo que corre
solo.
Seis workflows de integración continua, diez tareas programadas y los automatismos que dispara el propio tráfico. Abajo está el último resultado real de cada uno, leído de GitHub y de mi propia bitácora. No es una descripción de cómo debería funcionar.
Integración continua
Nada llega a producción sin pasar por aquí. La verificación posterior al despliegue puede revertir sola lo que acaba de publicarse.
Pruebas con cobertura, build, end to end con Playwright y verificación del despliegue.
La etapa final espera hasta 8 minutos a que el endpoint de salud devuelva el commit recién desplegado, hace tres comprobaciones y revierte sola si dos de las tres salen insanas. También reporta sus métricas al panel del sitio.
Auditoría de dependencias y análisis estático con CodeQL.
Además del push, corre sola los domingos, para que una vulnerabilidad publicada después del último commit no espere al siguiente.
Auditoría de accesibilidad con axe sobre las páginas públicas.
Análisis dinámico con ZAP contra el despliegue de vista previa de la rama.
Solo en pull request: necesita un sitio desplegado al que atacar, y ese es el preview que Vercel publica por rama.
Introduce fallos a propósito en el código y comprueba si alguna prueba se entera.
La cobertura dice que una línea se ejecutó; esto dice si romperla se detecta. Corre los domingos porque es caro.
Al publicar un artículo, lo anuncia y avisa a los buscadores.
Solo se dispara si el push toca `src/content/notes/`.
Tareas programadas
El plan que uso permite una ejecución diaria por tarea, así que lo que necesita más frecuencia lo dispara un programador externo contra el mismo endpoint, con el mismo secreto. Cada ejecución autorizada queda anotada: un cron que deja de dispararse no produce un error, produce silencio.
| Tarea | Cuándo | Origen | Qué hace | Última |
|---|---|---|---|---|
| backup | 03:00 | vercel | Copia de seguridad diaria de la base.Si falla: Se envejece la última copia disponible para restaurar. | sin registro |
| portal-demo-reseed | 04:00 | vercel | Repuebla la base de la demo pública con datos ficticios.Si falla: La demo va acumulando lo que hayan dejado los visitantes. | sin registro |
| monitor-rollup | 05:00 | vercel | Resume los sondeos del día en una fila por monitor.Si falla: El historial de disponibilidad deja de consolidarse y consultarlo se vuelve caro. | hace 7 h |
| uptime-check | 07:00 | vercel | Sondeo de disponibilidad, refresco de certificados, gestión de incidentes y purga de historial.Si falla: Una caída deja de abrir incidente y nadie se entera. | hace 1 min |
| domain-check | 08:00 | vercel | Vigila el vencimiento de los dominios y avisa, sin repetir el aviso.Si falla: Un dominio puede vencer sin previo aviso. | hace 5 h |
| indexnow | 08:30 | vercel | Reenvía el sitemap a los buscadores que admiten IndexNow.Si falla: El contenido nuevo tarda más en indexarse. | hace 4 h |
| invoices-overdue | 09:00 | vercel | Marca facturas vencidas y notifica.Si falla: Una factura vencida se queda figurando al día. | hace 4 h |
| uptime-check | cada ~5 min | cron-job.org | El mismo sondeo, a la frecuencia que la monitorización necesita de verdad.Si falla: La resolución del monitoreo cae a una medición al día. | hace 1 min |
| security-rollup | cada ~15 min | cron-job.org | Agrega la última hora de eventos, contrasta contra la línea base y aplica el bloqueo automático.Si falla: La detección de anomalías se queda sin agregados con los que comparar. | hace 6 min |
| sena-recordatorio | diario | cron-job.org | Recordatorio de la calculadora de etapa productiva.Si falla: Se pierde el recordatorio del día. | sin registro |
Automatismos del producto
Estos no los dispara un calendario ni un push, sino el propio tráfico.
Apertura y cierre de incidentes
Un sondeo fallido abre incidente; el primero que vuelve a salir bien lo cierra.
En cada sondeoBloqueo automático de abuso
Una intención inequívocamente maliciosa bloquea el origen, con salvaguardas para no bloquear a la propia infraestructura ni al administrador, y un tope por encima del cual avisa en vez de bloquear.
En línea con el request, y al agregar cada horaDetección de anomalías
Compara la hora cerrada contra la línea base histórica y señala lo que se sale de rango.
Al cerrar cada horaModo respaldo del portal
Si la base no responde, el portal sirve un snapshot versionado y lo anuncia; se apaga solo cuando la base vuelve.
Al detectar la base caídaReversión post-despliegue
Si el sitio recién publicado no responde sano, el pipeline revierte a la versión anterior y avisa.
Después de cada despliegue a producciónPurga de retención
El historial viejo se borra por capas para que la base no crezca sin límite.
Dentro de los crons de resumen