Practical guide
When a Local Heartbeat History Is a Poor Fit
The overnight backup misses its expected heartbeat at 2:00 a.m. The history can classify the silence as late, then down. Nobody opens the file until 8:11.
The classification is correct and six hours too quiet.
That is the 2 a.m. test. If a job must be received, evaluated, reported, shared, or preserved while the reviewer is asleep, a supplied heartbeat history is too small for the whole job.
Start with what the smaller process can prove
The file-based process begins with a monitor definition and ordered observations supplied by a person or another process. Each observation reports success, failure, or a time to evaluate. The result can show healthy, late, down, or recovered under the supplied period and grace rules.
A durable version stores bounded monitor history in a protected SQLite file. Its corrected export reads each monitor’s state and history from one database snapshot, which keeps those parts internally consistent. The history remains available for local inspection and stable JSON export.
Those functions answer a review question: given this configuration, these observations, and this time, what state follows?
They do not receive the next event, wake at the next expected time, contact a recipient, assign user permissions, or establish a time-based archive. Use the five tests below to decide whether those missing responsibilities belong inside your monitoring job.
Test 1: events must arrive without a reviewer
Choose a telemetry service when the monitored job must report while nobody is preparing a file.
Cronitor’s Telemetry API documents an HTTP endpoint for job and heartbeat events. Its examples include run, complete, and fail events for jobs, plus heartbeat events for periodic system health. It also documents email as another event-input method.
The local process receives observations already supplied to it. If the backup crashes at 2:00 a.m. and no event reaches the input file, there is nothing new to classify.
Poor-fit signal: the monitor must receive evidence directly from an unattended job.
Test 2: the clock must evaluate the schedule
Choose scheduled monitoring when the expected time must be checked without someone starting a review.
Cronitor’s cron job monitoring guide describes expected schedules, grace periods, and failure or schedule tolerances. It also describes alerts when jobs fail or miss their schedule.
The local rules can compare supplied times with a period and grace value. They do that work when the process runs. A laptop that is closed at 2:00 a.m. does not advance the evaluation by possessing the rule in a file.
Poor-fit signal: the clock must initiate the check when no reviewer is present.
Test 3: a state change must reach someone
Choose alert delivery when a missed job must contact a person or another system.
Cronitor’s Alerts & Issues guide describes notification lists that select recipients and channels. The documented choices include email, SMS, chat services, incident-management services, and webhooks. Its issues collect failure, alert, and recovery context for review.
The local output can record that a state changed. That record remains data until another process delivers it. A down label inside JSON cannot wake the person carrying the on-call phone.
Poor-fit signal: the response depends on a message reaching a configured recipient.
Test 4: several people need controlled access
Choose account-based access when engineers, managers, or outside reviewers need different permissions around the same monitoring record.
Cronitor’s team and user-role guide describes invitations and three roles: read-only, user, and administrator. Those roles divide viewing, daily management, and team administration.
The local history lives in files on one computer. Giving someone a copy does not create a shared current record, identify who changed a setting, or limit what each person can manage.
Poor-fit signal: the monitoring process needs named users and different levels of control.
Test 5: history must follow a defined retention rule
Choose a service or design a separate archive when the organization must preserve a known period of monitoring evidence.
The local history keeps a bounded number of entries for each monitor. Older entries leave that window as new ones arrive. Replay records are bounded too. Those count limits prevent unbounded growth, but they do not define a calendar retention period, backup plan, or restoration process.
Cronitor’s Monitor API guide describes recent telemetry events and recent job invocations in monitor details. It also says historical data remains preserved when job or heartbeat monitors are paused. Those are service record functions, not properties of the local file.
Poor-fit signal: later review depends on a stated retention period, recovery plan, or shared incident history.
Keep the file when review is the entire job
The smaller process fits when the event set already exists and one person needs to inspect what it supports. It can help reconstruct a failure sequence, challenge an unsupported state, compare a correction, or prepare a stable record for another review.
It also fits a controlled exercise before a monitoring setup changes. Supply the same observations and times, then compare the resulting state and history. The useful proof stays inside the inputs and outputs you can inspect.
Reject it as the whole monitoring system when any step must occur unattended. Receiving, schedule evaluation, delivery, account control, and retention each need an owner beyond the heartbeat file.
Takeaway
A local heartbeat history explains supplied events. It becomes a poor fit when the job includes noticing, acting, coordinating, or preserving evidence while nobody is reviewing the file.
Run the 2 a.m. ownership drill
Pick one overnight job and write five timestamps down the page: event sent, event received, schedule evaluated, person notified, history preserved. Beside each timestamp, name the system or person responsible when the review computer is closed. Any blank names a service responsibility that the local history cannot cover.