Anomaly Detection

Detect duration, schedule, and error-rate changes without hand-tuned alert thresholds.

Pro Feature

Anomaly detection is available on Pro and Business plans.

Overview

Anomaly detection watches the historical behavior of each heartbeat and alerts when the job starts behaving differently, even if it still checks in before the normal down alert fires.

Cronping builds a rolling baseline from recent pings and checks three independent signals:

Signal	What it catches	Default threshold
Duration spike	A successful or warning run took much longer than usual	Latest duration is more than `2.5x` the median of recent runs
Interval drift	Pings are arriving with a less stable cadence than usual	Current interval variation exceeds the baseline by `1.5x`
Error-rate surge	Warnings or failures are clustering in the last 24 hours	24-hour warn/fail rate is more than `3x` the 30-day baseline

How it works

Enable anomaly detection on a heartbeat.
Cronping collects enough historical pings to build a reliable baseline.
The worker periodically recalculates the baseline and compares recent behavior with that baseline.
If a signal crosses its threshold, Cronping records an anomaly and sends alerts through the heartbeat's configured email and integration channels.
When the signal returns to normal, the active anomaly is resolved automatically.

The detector runs in the background. You do not need to change the ping URLs or request payloads.

Baseline requirements

Anomaly detection needs history before it can make useful comparisons.

Setting	Default	Description
Minimum pings for baseline	`20`	A signal is skipped until it has enough samples
Duration sample window	Last `30` successful or warning runs	Used for the median duration baseline
Interval sample window	Recent terminal pings	Used to calculate interval variation
Error-rate window	Last `24h` vs previous `30d`	Used to detect a sudden warn/fail surge

For new heartbeats, the anomaly card may be empty until enough pings have arrived.

Configuration

Open a heartbeat, choose Edit, and use the Anomaly Detection section.

Field	Description
Enable anomaly detection	Turns all anomaly checks on or off for the heartbeat
Duration spikes	Alerts when run duration exceeds the learned median by the configured factor
Duration spike factor	Multiplier used for duration alerts, default `2.5`
Interval drift	Alerts when ping cadence becomes significantly less stable
Error-rate surges	Alerts when warnings or failures cluster in the last 24 hours
Alert cooldown	Minimum time before Cronping sends another alert for the same anomaly type
Minimum pings for baseline	Required historical samples before a signal is considered reliable

Anomaly detection is enabled by default for new heartbeats on plans that include it. The Management API defaults it to disabled unless anomalyEnabled is explicitly sent.

Alerts

Anomaly alerts use the same notification channels as heartbeat down alerts:

Email
Slack, Discord, Microsoft Teams, Telegram
Webhooks
PagerDuty, Incident.io
Gotify, ntfy, Pushover, Pushbullet

The alert includes the anomaly type, severity, and the measured value compared with the baseline. Webhooks receive anomaly events with event names such as heartbeat.anomaly_duration, heartbeat.anomaly_interval, and heartbeat.anomaly_error_rate.

Reviewing anomalies

The dashboard shows active anomaly counts on the overview page. Each heartbeat detail page includes an Anomaly Detection card with:

Current baseline values
Recent anomalies
Severity
Detection and resolution timestamps

Resolved anomalies remain in the history table so you can see recurring patterns over time.

Management API fields

The heartbeat create and update endpoints accept these anomaly settings:

{
  "anomalyEnabled": true,
  "durationSpikeEnabled": true,
  "durationSpikeFactor": 2.5,
  "intervalDriftEnabled": true,
  "errorRateSurgeEnabled": true,
  "anomalyAlertCooldownHours": 24,
  "minPingsForBaseline": 20
}

Setting anomalyEnabled to true requires a Pro or Business plan.