Keep scheduled jobs on watch

Find the right view of your watch

Monitors has four views: All monitors, Endpoint monitors, Job heartbeats and Domains & DNS. Endpoint monitors make requests; heartbeats wait for your jobs to send signals. Search, groups, tags and pagination apply within the selected view. Switching views starts a fresh selection and page.

Heartbeat cards show the last signal, next expected signal or completion deadline, and latest run duration when available. A paused monitor shows that its waiting window will restart on resume. Recent results include missing-signal checks as well as reported outcomes. These views share your existing monitor allowance, permissions, incidents and notifications.

Give your job a way to report in

A heartbeat monitor waits for your job to contact UptimeOwl. It never calls or starts the job. All plans can use heartbeats within their monitor allowance and minimum interval.

1. Open Monitors → Job heartbeats, choose Add monitor → Watch a scheduled job and give it a clear name.
2. Set Expected every to the normal time between successful runs, from your plan minimum up to 7 days. Add a grace period for normal variation, up to 24 hours.
3. Save. New heartbeats created in the editor start paused. On the monitor card, choose the key icon to generate a credential.
4. Copy the displayed curl command into your job’s secret configuration. It is shown only once. Run it only after successful work, then resume the monitor.

Send a sign of success

Send an empty POST to the displayed HTTPS endpoint with Authorization: Bearer followed by your credential. Keep the credential in a header, not a query string or public log. A successful response is HTTP 202. A browser visit, GET request or request with a body is not a heartbeat.

Use your-job && curl … so a failed job does not send a success ping. Our command has a ten-second network timeout. If delivery fails, retry with bounded backoff; it does not rerun your job. HTTP 429 asks you to retry after the indicated delay, while 503 means delivery is temporarily unavailable.

Every accepted standalone ping extends the deadline, including early runs. Repeated completions for the same run do not extend it. Rapid healthy pings are combined in check history according to the plan’s minimum interval, but none of those accepted signs of life is discarded. The recorded response field tells you whether a history row was added. Paired start and completion signals measure runtime separately, as described below.

When the nest grows quiet

After resuming, the job has one expected interval plus grace to send its first ping. If that deadline passes, the monitor reports down and the existing incident and notification rules apply. A subsequent success signal recovers it. Detection may follow shortly after the deadline while the scheduler picks up work.

Heartbeat monitors use one failure and one success for confirmation; the grace period handles passing delays. While a heartbeat remains missing, periodic failed checks maintain its history without opening duplicate incidents. Response-time charts do not represent job duration.

Pause stops deadline checks and rejects pings with HTTP 409. Suspended workspaces reject pings with HTTP 403. Resuming gives the job a fresh interval plus grace. Maintenance suppresses alerts through the usual monitor rules; it does not run your job or replace its ping.

Follow a run from start to finish

Use the credential dialog’s Signal selector to copy start, success or failure commands. Start returns run.id. Select Finish a started run for a completion command and replace RUN_ID_FROM_START with that ID. Keep Authorization on every request.

One monitor follows one active job. A repeated start before the runtime deadline returns the same ID without extending the deadline. Do not overlap jobs; use separate monitors for independent tasks. A start never recovers an incident. Success recovers it, while failure reports a problem immediately through your existing notifications.

Maximum run time is optional, from 1 second to 7 days. When empty, the effective expected interval is used. Grace is added to this runtime deadline. A run that does not finish in time creates an incident. A late completion can still recover it until a newer run replaces it. New starts also respect your plan minimum interval.

The monitor card shows the latest run and duration; open its recent checks and Job details for recorded results. Duration uses server receipt times and includes network delay. It is not HTTP response time or a process CPU measurement. The next expected heartbeat is measured from completion.

When a signal needs another look

Retry the same completion with the same run ID if its response was lost. The same result is accepted without another history entry or deadline extension. A conflicting result, obsolete run ID or missing ID for an active run returns 409. Pausing, suspension/reactivation or changing heartbeat timing clears run correlation; start again after resuming.

After the runtime deadline, a new start can replace an unfinished run. Old completion requests are then rejected. Only the latest run supports completion retries; this is not a historical execution API. Standalone success-only commands still work when no run is active, and standalone failure commands can report a failed job without measuring runtime.

Maintenance keeps its usual alert suppression. A run completed during maintenance stays suppressed on retry; send a new successful signal after the window to refresh health. HTTP 429 means wait for Retry-After, and 503 means retry with bounded backoff. Check the job’s own logs for its failure details; do not send logs or secrets in the heartbeat body.

Keep the credential safe

Owners and admins with monitor-management access can generate credentials. Generating another credential immediately invalidates the old one: update every job using it. Lost credentials cannot be retrieved. Deleted monitors no longer accept their credentials.

Exports preserve the heartbeat interval and grace settings, but never credentials. Imported monitors start paused and require a new credential. Widgets and status pages receive monitor health, not credentials or heartbeat configuration. Create a separate monitor rather than converting an HTTP, TCP, TLS or WebSocket monitor to a heartbeat.