Set Up Crons

Sentry Crons allows you to monitor the uptime and performance of any scheduled, recurring job in your application.

Once implemented, it'll allow you to get alerts and metrics to help you solve errors, detect timeouts, and prevent disruptions to your service.

If you are using Quartz, please see our Quartz integration. If you are using Spring Boot with @Scheduled tasks, see our Spring Boot integration.

Check-in monitoring allows you to track a job's progress by completing two check-ins: one at the start of your job and another at the end of your job. This two-step process allows Sentry to notify you if your job didn't start when expected (missed) or if it exceeded its maximum runtime (failed).

The Sentry Java SDK offers a helper that takes care of wrapping your code and sending a check-in at the start and one at the end. It checks for exceptions and sets the status of the check-in accordingly.

Copied
import io.sentry.util.CheckInUtils;

String result = CheckInUtils.withCheckIn("<monitor-slug>", () -> {
    // Execute your scheduled task here...
    return "computed result";
});

You may also send a MonitorConfig with a MontiorSchedule so the monitor is created or updated (upsert) automatically.

Copied
import io.sentry.MonitorConfig;
import io.sentry.MonitorSchedule;
import io.sentry.MonitorScheduleUnit;
import io.sentry.util.CheckInUtils;

MonitorConfig monitorConfig = new MonitorConfig(MonitorSchedule.interval(3, MonitorScheduleUnit.MINUTE));

String result = CheckInUtils.withCheckIn("<monitor-slug>", monitorConfig, () -> {
    // Execute your scheduled task here...
    return "computed result";
});

You can also check-in to a specific environment.

Copied
import io.sentry.MonitorSchedule;
import io.sentry.MonitorScheduleUnit;
import io.sentry.util.CheckInUtils;

String result = CheckInUtils.withCheckIn("<monitor-slug>", "<environment-name>", () -> {
    // Execute your scheduled task here...
    return "computed result";
});

It is also possible to manually send check-ins.

Copied
import io.sentry.CheckIn;
import io.sentry.CheckInStatus;
import io.sentry.Sentry;
import io.sentry.protocol.SentryId;

// 🟡 Notify Sentry your job is running:
SentryId checkInId = Sentry.captureCheckIn(
    new CheckIn(
        "<monitor-slug>",
        CheckInStatus.IN_PROGRESS
    )
);

// Execute your scheduled task here...

// 🟢 Notify Sentry your job has completed successfully:
Sentry.captureCheckIn(
    new CheckIn(
        checkInId,
        "<monitor-slug>",
        CheckInStatus.OK
    )
);

If your job execution fails, you can notify Sentry about the failure:

Copied
// 🔴 Notify Sentry your job has failed:
Sentry.captureCheckIn(
    new CheckIn(
        checkInId,
        "<monitor-slug>",
        CheckInStatus.ERROR
    )
);

Heartbeat monitoring notifies Sentry of a job's status through one check-in. This setup will only notify you if your job didn't start when expected (missed). If you need to track a job to see if it exceeded its maximum runtime (failed), use check-ins instead.

Copied
import io.sentry.CheckIn;
import io.sentry.CheckInStatus;
import io.sentry.Sentry;
import io.sentry.protocol.SentryId;

// Execute your scheduled task...

// 🟢 Notify Sentry your job completed successfully:
CheckIn checkIn = new CheckIn(
    "<monitor-slug>",
    CheckInStatus.OK
);
checkIn.setDuration(10.0);
Sentry.captureCheckIn(checkIn);

If your job execution fails, you can:

Copied
import io.sentry.CheckIn;
import io.sentry.CheckInStatus;
import io.sentry.Sentry;
import io.sentry.protocol.SentryId;

// 🔴 Notify Sentry your job has failed:
CheckIn checkIn = new CheckIn(
    "<monitor-slug>",
    CheckInStatus.ERROR
);
checkIn.setDuration(10.0);
Sentry.captureCheckIn(checkIn);

You can create and update your Monitors programmatically with code rather than creating and configuring them in Sentry.io.

Copied
import io.sentry.MonitorSchedule;
import io.sentry.MonitorScheduleUnit;

// Create a crontab schedule object (every 10 minutes)
MonitorSchedule monitorSchedule = MonitorSchedule.crontab("*/10 * * * *");

// Or create an interval schedule object (every 10 minutes)
MonitorSchedule monitorSchedule = MonitorSchedule.interval(10, MonitorScheduleUnit.MINUTE);

Supported units are:

  • MonitorScheduleUnit.MINUTE
  • MonitorScheduleUnit.HOUR
  • MonitorScheduleUnit.DAY
  • MonitorScheduleUnit.WEEK
  • MonitorScheduleUnit.MONTH
  • MonitorScheduleUnit.YEAR
Copied
import io.sentry.MonitorConfig;

// Create a config object
MonitorConfig monitorConfig = new MonitorConfig(monitorSchedule);
monitorConfig.setTimezone("Europe/Vienna"); // Optional timezone
monitorConfig.setCheckinMargin(5L); // Optional check-in margin in minutes
monitorConfig.setMaxRuntime(15L); // Optional max runtime in minutes
monitorConfig.setFailureIssueThreshold(2L); //Optional failure issue threshold
monitorConfig.setRecoveryThreshold(5L); // Optional recovery threshold

// 🟡 Notify Sentry your job is running:
CheckIn checkIn = new CheckIn(
    "<monitor-slug>",
    CheckInStatus.IN_PROGRESS
);
checkIn.setMonitorConfig(monitorConfig);
SentryId checkInId = Sentry.captureCheckIn(checkIn);

// Execute your scheduled task here...

// 🟢 Notify Sentry your job has completed successfully:
Sentry.captureCheckIn(
    new CheckIn(
        checkInId,
        "<monitor-slug>",
        CheckInStatus.OK
    )
);

When your recurring job fails to check in (missed), runs beyond its configured maximum runtime (failed), or manually reports a failure, Sentry will create an error event with a tag to your monitor.

To receive alerts about these events:

  1. Navigate to Alerts in the sidebar.
  2. Create a new alert and select "Issues" under "Errors" as the alert type.
  3. Configure your alert and define a filter match to use: The event's tags match {key} {match} {value}.

Example: The event's tags match monitor.slug equals my-monitor-slug-here

Cron completed alert filter

Learn more in Issue Alert Configuration.

Crons imposes a rate limit on check-ins to prevent abuse and resource overuse. Specifically, you can only send a maximum of 6 check-ins per minute per existing monitor environment. This limit is enforced on a per-project basis, meaning that the rate limit applies collectively to all monitor environments within a given project. You can check if any of your check-ins are being dropped in the Usage Stats page.

To avoid dropped check-ins, it is crucial to manage and distribute your check-ins efficiently within the rate limits. This will help maintain accurate monitoring and ensure that all critical check-ins are captured and processed.

Previous
Set Up Tracing
Next
Troubleshooting
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").