Skip to main content
Cron Monitoring watches your scheduled jobs and background tasks. Instead of only knowing a job failed (or never ran), you get visibility into every execution: when it started, how long it took, whether it succeeded, and whether it ran on time.

​
How it works

Your job sends a check-in to Sentry when it starts and again when it finishes. Sentry compares those check-ins against the expected schedule and marks the run as ok, failed, missed, or timed out. 
Job starts  →  send "in_progress" check-in
Job finishes →  send "ok" or "error" check-in

If no check-in arrives by the expected time → Sentry marks it as "missed"
If the "in_progress" check-in isn't closed in time → Sentry marks it as "timeout"

​
Check-in statuses

StatusWhat it means
in_progressThe job sent an opening check-in and is currently running
okThe job completed successfully
errorThe job explicitly reported a failure
missedNo check-in arrived within the expected window
timeoutThe job started (in_progress) but didn’t finish within max_runtime

​
Creating a monitor

1

Open Crons

In your Sentry project, navigate to Crons in the left sidebar.
2

Create a monitor

Click Add Monitor. Give it a name and a unique slug — you’ll use the slug in your check-in calls.
3

Configure the schedule

Choose a schedule type and set the expression:
  • Crontab: a standard 5-field cron expression (e.g. 0 * * * * for hourly)
  • Interval: a human-friendly interval (e.g. every 5 minutes, every 2 hours, every 1 day)
Supported interval units: minute, hour, day, week, month, year
4

Set tolerances (optional)

  • Check-in margin (checkin_margin): How many minutes after the expected time to wait before marking a run as missed. Useful for jobs that take a moment to start.
  • Max runtime (max_runtime): How many minutes a job can stay in_progress before Sentry marks it as timed out.
5

Save and instrument

Copy the monitor slug and add check-in calls to your job code (see below).

​
Sending check-ins

The SDK handles opening and closing check-ins automatically, and reports error status if an exception is raised. 
import sentry_sdk

# Wraps the code block: sends "in_progress" on enter, "ok" on exit, "error" on exception
with sentry_sdk.monitor(monitor_slug="my-nightly-job"):
    run_my_job()

​
Via HTTP API

You can also send check-ins directly to the Sentry API from any language or environment that can make HTTP requests. 
# Open a check-in (job starting)
curl -X POST \
  "https://sentry.io/api/0/organizations/{org-slug}/monitors/{monitor-slug}/checkins/" \
  -H "Authorization: Bearer <your-auth-token>" \
  -H "Content-Type: application/json" \
  -d '{"status": "in_progress"}'

# Close the check-in with the returned check-in ID
curl -X PUT \
  "https://sentry.io/api/0/organizations/{org-slug}/monitors/{monitor-slug}/checkins/{checkin-id}/" \
  -H "Authorization: Bearer <your-auth-token>" \
  -H "Content-Type: application/json" \
  -d '{"status": "ok", "duration": 3200}'

​
Via DSN (upsert)

If you’d rather not create monitors in the UI first, you can upsert a monitor directly from your check-in payload using your project DSN. Include the full monitor config in the check-in envelope:
Python
import sentry_sdk

sentry_sdk.init(dsn="https://your-dsn@sentry.io/project-id")

with sentry_sdk.monitor(
    monitor_slug="my-nightly-job",
    monitor_config={
        "schedule": {"type": "crontab", "value": "0 2 * * *"},
        "checkin_margin": 5,
        "max_runtime": 30,
        "timezone": "America/New_York",
    },
):
    run_my_job()
Upsert check-ins create or update the monitor configuration automatically. This is useful when you manage monitors as code alongside your job definitions.

​
Schedule types

​
Crontab

Use standard 5-field cron syntax. Sentry also supports common aliases:
AliasEquivalent
@yearly / @annually0 0 1 1 *
@monthly0 0 1 * *
@weekly0 0 * * 0
@daily0 0 * * *
@hourly0 * * * *

​
Interval

Specify a count and a unit: 
{"type": "interval", "value": 5, "unit": "minute"}
{"type": "interval", "value": 2, "unit": "hour"}
{"type": "interval", "value": 1, "unit": "day"}

​
Alerting

By default, Sentry creates an issue whenever a monitor enters a failed state (missed, error, or timeout). You can configure additional alert rules to notify your team:
  • Email — send to specific team members or the issue assignee
  • Slack — post to a channel
  • PagerDuty — page on-call
  • Webhooks — call any HTTP endpoint
Configure alert rules under Settings > Alerts or directly from the monitor’s Alert Rules tab.
Use the failure_issue_threshold setting to require multiple consecutive failures before an issue is created. This reduces noise from transient failures in flaky jobs.

​
Environments

Each monitor tracks check-ins per environment. If the same job runs in production and staging, Sentry creates separate environment tracks under the same monitor. Set the environment in your check-in: 
with sentry_sdk.monitor(monitor_slug="my-job", monitor_config={...}):
    # Pass environment via SDK scope
    with sentry_sdk.new_scope() as scope:
        scope.set_tag("environment", "production")
        run_my_job()