A missing backup or stalled scheduled task may never send an error. WarnFire Heartbeats watches for expected check-ins and sends failures through the owning service's incident response plan.
A backup every two hours and a report due at 2 a.m. make different promises. Set the expected schedule, timezone, grace period, maximum runtime, and tolerance for missed check-ins.
Read the product guideUse an interval for work expected every fixed amount of time, or cron and supported readable expressions for a calendar schedule. A 24-hour interval stays 24 hours; a daily local time follows daylight saving changes in the chosen timezone.
A grace period gives a scheduled job time to check in before it counts as missing. Missed-check tolerance lets you decide how many expected check-ins can be missed before an incident opens.
Send start and completion check-ins for each run. A maximum runtime detects work that began but never reported completion, covering a failure that a success-only ping cannot explain.
WarnFire observes the work; your scheduler still starts it. Changing a monitor’s expectation does not change a cron entry, container schedule, or Windows task on the machine running the job.
Illustrative settings for scheduled jobs. Configure the monitor to match the scheduler that actually runs the work.
| Workload | Expectation | What stays consistent |
|---|---|---|
| Recurring backup | Every 2 hours | Elapsed time between expected check-ins |
| Daily report | At 02:00 in America/Los_Angeles | The local clock time, across daylight saving changes |
| Started but stalled job | Start and completion check-ins, with a maximum runtime | A recorded start must be followed by completion within the allowed time |
Use a monitor’s secret ping address for a simple integration, or wrap a command with the WarnFire client. Keep the task with its existing scheduler and add evidence about each execution.
Read the product guideClient setup paths cover Linux, macOS, and Windows, including cron, systemd, launchd, and Task Scheduler. Wrap the command you already run so it can report its start, completion, and exit code.
Connect Docker jobs and Kubernetes CronJobs to the monitor expecting their check-ins. The product guides explain container setup and Kubernetes context, namespace, and Secret handling.
Include bounded diagnostic output with the run so the responder can see what happened. Command wrappers keep the monitor credential out of the child process’s environment and preserve the command’s original exit code.
A monitor’s ping credential reports check-ins; it is separate from a management API key. Store it as a secret and rotate it when access changes. One job does not need the credentials for every other job.
A process exit code can say more than “finished.” Map the codes your job actually uses to success, warning, error, or critical, then inspect the evidence behind each outcome.
Read the product guideUse reusable exit-code sets for individual codes or ranges. Success and warning are accepted completions; both reset the failure count and can resolve the monitor’s incident. A warning remains visible in run history without paging.
Error and critical outcomes count toward the configured failure threshold. A critical result does not bypass that tolerance. Once an incident opens, the service’s escalation policy determines the response for its severity.
Inspect expected times, received check-ins, diagnostic notes, raw exit codes, and the outcome mapping recorded for the run. Later edits to an exit-code set do not rewrite completed runs.
The wrapper returns the process’s original exit code. Mapping a nonzero code to an accepted outcome in WarnFire does not change your scheduler’s retry behavior.
Attach the monitor to a service and use its schedules, severity rules, channels, and escalation policy. Scheduled work follows the same response path as your other incidents.
Read the product guideChoose the service responsible for the job. Its response plan decides who is contacted, how long to wait, and when to escalate. A failed backup should reach its owner with the run evidence available.
Use monitor groups to organize related work while retaining each monitor’s schedule and history. A group helps you navigate; it does not replace the owning service’s routing or automatically publish customer status.
Pause monitoring while planned work changes what should be running, then resume when it is ready. Review shared-service effects when maintenance covers several monitors.
An optional surge guard can pause further notifications after the configured number of escalation dispatches. Monitoring, run history, incidents, and recovery continue. Review and resume deliberately; withheld notifications are not replayed.
Start a workspace, connect a service, and make the next signal reach its owner.
