How Cronwize keeps its own failures out of your alerts.
A monitor is only useful if its alerts are believed. These are the rules the checker follows, and what it does not promise.
One tick per day. Hatched: a day with minutes when Cronwize could not receive pings. Checks that fell into those minutes were moved to the job's next run.
Our outage is never your alert
Every minute in which pings could be received is recorded. An expected ping that fell into a gap is not counted as missed; the monitor's history says so.
An alert is written with the state change
The notification is stored in the same database transaction that marks a monitor down, so a crash between the two cannot lose it.
The checker is watched
An independent watchdog pages the operator if the minute checker stops running, because the scheduler underneath it is best effort.
Checks are idempotent
A missed or doubled scheduler run is reconciled on the next one, and each miss is designed to produce one alert, not two.
No "never miss a job". No "100% uptime".
Cronwize runs on Vercel in Frankfurt with a Supabase database in the same region. Push depends on Google and Apple, email on ZeptoMail. Any of these can fail.
The checker runs once a minute on a best-effort scheduler, so a job expected at 02:00 with a 10-minute grace period alerts shortly after 02:10. The design target is within 2 minutes.
If a job really fails during a Cronwize outage, you hear about it one run later.