Schedule and grace

The monitor waits for a ping until the expected time plus grace. A missing signal counts as a failure; an incident opens at the configured failure threshold. Alerts use connected channels and respect quiet hours, maintenance windows and notification muting.

Choosing the grace period

Grace controls how late an expected signal may arrive. If you send only a final ping, allow for queueing and execution time. To monitor runtime separately, send /start and configure a maximum duration.

Too tight is worse than too loose. False alarms train people to ignore notifications — and the real outage gets lost among them.

Maximum duration

If the job sends a start signal, we also watch how long it runs. The deadline is the earlier of two points: “expected time plus grace” and “start plus maximum duration”. A hung job is caught without waiting for the next scheduled run.

Unusually slow successful runs

Each monitor has a duration chart, median and usual range. Measurements require /start followed by a successful finish. We compare with up to 20 preceding successful measurements within 90 days, with a minimum of 10. The current run is excluded from its own baseline.

Statistics are available on every plan; automatic warnings start with Start. By default, duration must exceed 3× the median, a 30-second increase and normal variability. Sensitivity and the alert switch are in the monitor detail. Connected channels receive at most one warning per monitor per 24 hours, respecting quiet hours and maintenance. A slow successful job does not create an outage or change public status.

Timezones and DST

Cron schedules are evaluated in the monitor timezone, including clock changes. Use the same timezone as your scheduler. Handling of skipped or repeated hours depends on the scheduler: check jobs scheduled around the transition and choose suitable grace.