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 plan capacity. |
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 30-day run-history window. 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. 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.