Understand lifecycle and outcomes
CronRadar separates the health of an automation from the result of its latest execution. That distinction explains both whether action is needed and why.
Execution lifecycle
| Event | Meaning | Effect |
|---|---|---|
start | The job began | Marks the automation as running and starts duration measurement. |
complete | The job returned successfully | Records success, duration, and recovery when applicable. |
fail | The job reported an exception or failure | Records failed and creates an incident immediately. |
| heartbeat | The job completed successfully without explicit start tracking | Records success; duration and stuck-run detection are unavailable for that run. |
Use a wrapper or framework integration when possible. It guarantees that successful returns complete, user exceptions fail, and the original user exception is rethrown.
Health states
| Health | What you can observe |
|---|---|
pending | The automation is known but has no execution result yet. |
healthy | The latest evidence is on time and successful, or a run is currently in progress. |
warning | The expected run is late but still inside its grace period. |
critical | A run failed, exceeded its expected window, or did not report. |
paused | Monitoring is deliberately disabled or discovery exceeded the Free plan limit. |
Failure modes
- Missed or late: no expected signal arrived; warning becomes critical after grace expires.
- Failed: the job ran and explicitly reported failure.
- Stuck: a start arrived but no completion or failure followed before the expected window.
- Disappeared: a previously discovered recurring job is absent from an authoritative scheduler reconciliation. CronRadar pauses it rather than deleting history.
Bounded outcome checks
An automation may define up to five expectations such as records_processed >= 1, errors = 0, files_produced >= 1, or successful is true. Report matching finite numbers or booleans with the completion event. A missing or violated expectation marks the completed run outcome-failed, opens an incident, and explains the observed and expected values.
Only configured outcome keys are retained. Outcome evidence follows the billing owner's run-history window: 30 days on Free, 90 days on Grow. Alert history is 90 days on Free and 180 days on Grow. Longer history cannot restore records already deleted; when a downgrade becomes effective, the next daily cleanup applies the shorter window. Operational settings can extend these windows up to 365 days, but cannot shorten a plan's included history. Never send job payloads, arguments, database records, logs, secrets, tokens, or personal data.
Once checks are configured, report a full lifecycle completion with its outcome values. A heartbeat-only report has no outcome body, so configured checks are treated as missing for that run.
Schedules and grace
Base SDK and HTTP integrations use standard five-field cron expressions, evaluated in UTC; see cron schedule syntax. Framework integrations translate scheduler-native schedules when they can do so without changing meaning. Grace begins after the next expected time and prevents transient lateness from immediately opening an incident. The service enforces a minimum of 60 seconds; the product default is 90 seconds unless the application or integration supplies another valid value.
Priority and routing
Each monitor can carry an owner, a severity (Warning, Error, or Critical), an environment, and alert destinations. An owner, severity, or destination list left blank inherits from the application, then the workspace. Severity appears in Slack, Discord, PagerDuty, and webhook alerts and sets the PagerDuty event severity; it does not change detection timing or which destinations receive the alert. To decide each job's severity, grace period, and destinations from what its failure costs, see the CronRadar Scheduled Job Methodology.