What runs
on its own.
6 continuous integration workflows, 10 scheduled tasks and the automations traffic itself triggers. Below is thelast real result of each one, read from GitHub and from my own run log. It is not a description of how it ought to work.
Continuous integration
Nothing reaches production without going through here. The post-deploy verification can roll back what was just published, on its own.
Tests with coverage, build, end to end with Playwright and post-deploy verification.
The final stage waits up to 8 minutes for the health endpoint to report the commit that was just deployed, runs three checks and rolls back on its own if two of the three come back unhealthy. It also reports its metrics to the site dashboard.
Dependency audit and static analysis with CodeQL.
Beyond the push, it also runs by itself on Sundays, so a vulnerability published after the last commit does not have to wait for the next one.
Accessibility audit with axe over the public pages.
Dynamic analysis with ZAP against the branch preview deployment.
Pull requests only: it needs a deployed site to attack, and that is the preview Vercel publishes per branch.
Injects faults into the code on purpose and checks whether any test notices.
Coverage says a line ran; this says whether breaking it gets caught. It runs on Sundays because it is expensive.
When an article ships, it announces it and pings the search engines.
It only fires when the push touches `src/content/notes/`.
Scheduled tasks
The plan I am on allows one run a day per task, so anything that needs more frequency is fired by an external scheduler against the same endpoint, with the same secret. Every authorized run is written down: a cron that stops firing does not produce an error, it produces silence.
| Task | When | Source | What it does | Last run |
|---|---|---|---|---|
| backup | 03:00 | vercel | Daily backup of the database.If it fails: The newest copy available to restore from keeps getting older. | 2 h ago |
| portal-demo-reseed | 04:00 | vercel | Reseeds the public demo database with fictional data.If it fails: The demo piles up whatever visitors left behind. | 2 h ago |
| monitor-rollup | 05:00 | vercel | Rolls up the day's probes into one row per monitor.If it fails: The uptime history stops being consolidated and reading it turns expensive. | 28 min ago |
| computo-rollup | 06:00 | vercel | Consolidates the compute usage measured on each client project and recalculates what gets billed for it.If it fails: Usage is still measured, but the current period stops reflecting it until the next pass. | no record |
| uptime-check | 07:00 | vercel | Uptime probe, certificate refresh, incident handling and history purge.If it fails: An outage stops opening an incident and nobody finds out. | just now |
| domain-check | 08:00 | vercel | Watches domain expiry and warns once, without repeating itself.If it fails: A domain can expire with no warning at all. | no record |
| indexnow | 08:30 | vercel | Resubmits the sitemap to the search engines that support IndexNow.If it fails: New content takes longer to get indexed. | no record |
| invoices-overdue | 09:00 | vercel | Flags overdue invoices and notifies.If it fails: An overdue invoice keeps showing up as current. | no record |
| uptime-check | every ~5 min | cron-job.org | The same probe, at the frequency monitoring actually needs.If it fails: Monitoring resolution drops to one measurement a day. | just now |
| security-rollup | every ~15 min | cron-job.org | Aggregates the last hour of events, compares it against the baseline and applies automatic blocking.If it fails: Anomaly detection is left without aggregates to compare against. | 10 min ago |
| sena-recordatorio | 12:00 | cron-job.org | Reminder from the apprenticeship-stage calculator.If it fails: The day's reminder is lost. | no record |
Product automations
These are fired by traffic itself, not by a calendar or a push.
Opening and closing incidents
A failed probe opens an incident; the first one that comes back healthy closes it.
On every probeAutomatic abuse blocking
Unmistakably malicious intent blocks the source, with safeguards against blocking the infrastructure itself or the administrator, and a ceiling above which it warns instead of blocking.
Inline with the request, and on every hourly aggregationAnomaly detection
Compares the closed hour against the historical baseline and flags whatever falls out of range.
As each hour closesPortal fallback mode
If the database stops answering, the portal serves a versioned snapshot and says so; it turns itself off when the database returns.
When the database is detected as downPost-deploy rollback
If the freshly published site does not answer healthy, the pipeline reverts to the previous version and warns.
After every production deploymentRetention purge
Old history is deleted in layers so the database does not grow without bound.
Inside the rollup crons