Seiri guides
Scheduled job monitoring
Scheduled job monitoring covers anything that must run on a clock: digests, invoices, backups, ETL, reports. Seiri uses heartbeats so a missed window becomes an alert.
Common failure modes
Scheduled work fails without an exception more often than teams expect. The host is up, the dashboard is green, and the only missing signal is the run itself.
- ·Cron entry removed after a migration — config management or a host rebuild drops the line; nothing logs an error because nothing ran.
- ·Job starts but never finishes — hang, lock wait, or Kubernetes eviction leaves a process “running” forever with no success ping.
- ·Job “succeeds” but skips the real work — empty result set, bad feature flag, or guard clause exits 0 after a no-op.
- ·Schedule drift — DST, timezone config, or “every 6 hours” vs wall-clock slots means the monitor and the scheduler disagree.
How heartbeat monitoring fits
Seiri is push/heartbeat monitoring, not website uptime. Your job checks in when useful work finishes. If that check-in is late past the grace period, Seiri alerts Slack, Discord, email, SMS, or a webhook. It is also not a cron→webhook scheduler — it watches whether your scheduled job ran.
How to wire Seiri
Attach a ping to the end of a successful run (curl to your monitor URL, or email to @ping.seiri.app). For in-cluster workloads, install seiri-kube-agent and declare HealthCheck CRs. Deeper guide: scheduled job reliability.
# Ping only if the job succeeds
0 2 * * * /usr/local/bin/nightly-job.sh && curl -fsS https://ping.seiri.app/webhook/acme-demo:YOUR_REF/successFAQ
Is this for website uptime?
No — it is for scheduled and background work that must check in. Uptime tools poll URLs; Seiri waits for your job to prove it ran.
Cron jobs vs other schedulers?
Same model for crontab, Task Scheduler, CI cron, and batch pipelines — define the expected window, ping on success, alert on silence. See also cron job monitoring.