From 36d3b802e04e14408b013334b32e43fbcca6f754 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 2 Oct 2026 12:43:20 -0700 Subject: [PATCH 01/19] docs(crons): Document monitor config from @Scheduled for Spring @SentryCheckIn Co-Authored-By: Claude Opus 5.5 --- platform-includes/crons/requirements/java.mdx | 2 +- .../crons/setup/java.spring-boot.mdx | 20 +++++++++++++++++++ 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/platform-includes/crons/requirements/java.mdx b/platform-includes/crons/requirements/java.mdx index 13baa55a15e56..ad8b8a3e66697 100644 --- a/platform-includes/crons/requirements/java.mdx +++ b/platform-includes/crons/requirements/java.mdx @@ -6,5 +6,5 @@ - Send a monitor configuration from your code as shown below, and Sentry creates the monitor on the first check-in. You can also [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) instead. -- [Create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. `@SentryCheckIn` does not send a monitor configuration, so Sentry drops check-ins for a slug that has no monitor. +- From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` sends a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. With older SDK versions, or schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index a711aa8b2bcdb..02a2101791ae9 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -52,6 +52,26 @@ public class CustomJob { } ``` +### Monitor Configuration From `@Scheduled` + +From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in, so Sentry creates the monitor, or updates its schedule, from your code. The schedule is converted like this: + +- `cron`: a Spring cron expression with a fixed seconds field (for example `0 0 * * * *`) is sent as a crontab schedule without the seconds. Spring macros such as `@hourly` and `@daily` are supported. +- `fixedRate` and `fixedDelay` (including the `*String` variants and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. +- `zone`: sent as the monitor's timezone for cron schedules. + +Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. + +Sentry only updates the schedule and the fields that were sent, so settings such as margins configured in Sentry are kept. To manage the monitor's schedule in Sentry instead, turn this off: + +```java +@Scheduled(cron = "0 0 * * * *") +@SentryCheckIn(monitorSlug = "", upsertMonitorConfig = false) +void execute() { + // your task code +} +``` + ## Heartbeat 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. To start sending heartbeats simply add the `@SentryCheckIn(monitorSlug = "", heartbeat = true)` annotation to the method you want to send heartbeats for. From a8bb8a9cb4c06d6ebb88f9f739d8f164838ffbd8 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 2 Oct 2026 12:50:46 -0700 Subject: [PATCH 02/19] docs(crons): Note Spring zone default and short period strings --- platform-includes/crons/setup/java.spring-boot.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 02a2101791ae9..9dbe943a2234c 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -57,8 +57,8 @@ public class CustomJob { From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in, so Sentry creates the monitor, or updates its schedule, from your code. The schedule is converted like this: - `cron`: a Spring cron expression with a fixed seconds field (for example `0 0 * * * *`) is sent as a crontab schedule without the seconds. Spring macros such as `@hourly` and `@daily` are supported. -- `fixedRate` and `fixedDelay` (including the `*String` variants and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. -- `zone`: sent as the monitor's timezone for cron schedules. +- `fixedRate` and `fixedDelay` (including the `*String` variants, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. +- `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. From f4e5bf14d5729acc6e04ec68758f6440d72de682 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 2 Oct 2026 12:57:01 -0700 Subject: [PATCH 03/19] docs(crons): Make Spring @Scheduled monitor config opt-in Co-Authored-By: Claude Opus 5.5 --- platform-includes/crons/requirements/java.mdx | 2 +- .../crons/setup/java.spring-boot.mdx | 22 ++++++++++--------- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/platform-includes/crons/requirements/java.mdx b/platform-includes/crons/requirements/java.mdx index ad8b8a3e66697..1cdbe14933070 100644 --- a/platform-includes/crons/requirements/java.mdx +++ b/platform-includes/crons/requirements/java.mdx @@ -6,5 +6,5 @@ - Send a monitor configuration from your code as shown below, and Sentry creates the monitor on the first check-in. You can also [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) instead. -- From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` sends a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. With older SDK versions, or schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. +- From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn(value = "", upsertMonitorConfig = true)` sends a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Otherwise, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 9dbe943a2234c..ea008498d6715 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -54,24 +54,26 @@ public class CustomJob { ### Monitor Configuration From `@Scheduled` -From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in, so Sentry creates the monitor, or updates its schedule, from your code. The schedule is converted like this: - -- `cron`: a Spring cron expression with a fixed seconds field (for example `0 0 * * * *`) is sent as a crontab schedule without the seconds. Spring macros such as `@hourly` and `@daily` are supported. -- `fixedRate` and `fixedDelay` (including the `*String` variants, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. -- `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. - -Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. - -Sentry only updates the schedule and the fields that were sent, so settings such as margins configured in Sentry are kept. To manage the monitor's schedule in Sentry instead, turn this off: +From the next Sentry Java SDK release (after `8.59.0`), set `upsertMonitorConfig = true` and `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in, so Sentry creates the monitor, or updates its schedule, from your code: ```java @Scheduled(cron = "0 0 * * * *") -@SentryCheckIn(monitorSlug = "", upsertMonitorConfig = false) +@SentryCheckIn(value = "", upsertMonitorConfig = true) // 👈 void execute() { // your task code } ``` +The schedule is converted like this: + +- `cron`: a Spring cron expression with a fixed seconds field (for example `0 0 * * * *`) is sent as a crontab schedule without the seconds. Spring macros such as `@hourly` and `@daily` are supported. +- `fixedRate` and `fixedDelay` (including the `*String` variants, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. +- `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. + +Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods without `upsertMonitorConfig = true`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. + +Sentry only updates the schedule and the fields that were sent, so settings such as margins configured in Sentry are kept. + ## Heartbeat 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. To start sending heartbeats simply add the `@SentryCheckIn(monitorSlug = "", heartbeat = true)` annotation to the method you want to send heartbeats for. From 6773da4a2541236dc695203e52151b244cbe4ab7 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 2 Oct 2026 13:44:38 -0700 Subject: [PATCH 04/19] docs(java): Note Spring schedules that send no monitor config --- platform-includes/crons/setup/java.spring-boot.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index ea008498d6715..9400792d7d9f8 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -68,9 +68,9 @@ The schedule is converted like this: - `cron`: a Spring cron expression with a fixed seconds field (for example `0 0 * * * *`) is sent as a crontab schedule without the seconds. Spring macros such as `@hourly` and `@daily` are supported. - `fixedRate` and `fixedDelay` (including the `*String` variants, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. -- `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. +- `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. It must be an IANA time zone ID such as `Europe/Vienna`; whole-hour offsets such as `GMT+2` are sent as `Etc/GMT-2`. -Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods without `upsertMonitorConfig = true`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. +Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), cron expressions that set both day-of-month and day-of-week, cron syntax Sentry doesn't support (such as `15W`, `L-3`, or wrap-around ranges like `22-2`), other time zones, periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods without `upsertMonitorConfig = true`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. Sentry only updates the schedule and the fields that were sent, so settings such as margins configured in Sentry are kept. From a9c97ec6628e89406d1401382aa291b128adecae Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 2 Oct 2026 17:01:01 -0700 Subject: [PATCH 05/19] docs(crons): Note fixedDelay and options.cron defaults for Spring monitor config --- platform-includes/crons/setup/java.spring-boot.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 9400792d7d9f8..76550c642d008 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -67,12 +67,12 @@ void execute() { The schedule is converted like this: - `cron`: a Spring cron expression with a fixed seconds field (for example `0 0 * * * *`) is sent as a crontab schedule without the seconds. Spring macros such as `@hourly` and `@daily` are supported. -- `fixedRate` and `fixedDelay` (including the `*String` variants, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. +- `fixedRate` (including `fixedRateString`, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. `fixedDelay` jobs send no monitor config. - `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. It must be an IANA time zone ID such as `Europe/Vienna`; whole-hour offsets such as `GMT+2` are sent as `Etc/GMT-2`. Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), cron expressions that set both day-of-month and day-of-week, cron syntax Sentry doesn't support (such as `15W`, `L-3`, or wrap-around ranges like `22-2`), other time zones, periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods without `upsertMonitorConfig = true`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. -Sentry only updates the schedule and the fields that were sent, so settings such as margins configured in Sentry are kept. +Sentry only updates the fields that were sent. Margins, max runtime, and thresholds configured in Sentry are kept unless you set defaults for them in `options.cron`, which are sent with every check-in. ## Heartbeat From f794069c5cfe7ef3ecd8870f87fe0cf6400c7ef8 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 5 Oct 2026 12:24:05 -0700 Subject: [PATCH 06/19] docs(crons): Narrow the Spring day field limits and options.cron note Co-Authored-By: Claude --- platform-includes/crons/setup/java.spring-boot.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 76550c642d008..0bad5abf91be0 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -70,9 +70,9 @@ The schedule is converted like this: - `fixedRate` (including `fixedRateString`, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. `fixedDelay` jobs send no monitor config. - `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. It must be an IANA time zone ID such as `Europe/Vienna`; whole-hour offsets such as `GMT+2` are sent as `Etc/GMT-2`. -Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), cron expressions that set both day-of-month and day-of-week, cron syntax Sentry doesn't support (such as `15W`, `L-3`, or wrap-around ranges like `22-2`), other time zones, periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods without `upsertMonitorConfig = true`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. +Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), cron expressions that set both day-of-month and day-of-week (on Spring 5.3 and later, a day-of-month step such as `0 0 9 */2 * MON` is converted; on older Spring versions, none are), `#5` days of week on Spring 5.3 and later, cron syntax Sentry doesn't support (such as `15W`, `L-3`, or wrap-around ranges like `22-2`), other time zones, periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods without `upsertMonitorConfig = true`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. -Sentry only updates the fields that were sent. Margins, max runtime, and thresholds configured in Sentry are kept unless you set defaults for them in `options.cron`, which are sent with every check-in. +Sentry only updates the fields that were sent. Margins, max runtime, and thresholds configured in Sentry are kept unless you set defaults for them in `options.cron`, which are sent only with check-ins that carry a monitor configuration. ## Heartbeat From baa0f45e6a192a5d4f6c0bb094c794af1c3a380e Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 5 Oct 2026 16:08:23 -0700 Subject: [PATCH 07/19] docs(crons): Spring @Scheduled monitor config is on by default Co-Authored-By: Claude --- platform-includes/crons/requirements/java.mdx | 2 +- platform-includes/crons/setup/java.spring-boot.mdx | 8 +++++--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/platform-includes/crons/requirements/java.mdx b/platform-includes/crons/requirements/java.mdx index 1cdbe14933070..e47f9f562e3ad 100644 --- a/platform-includes/crons/requirements/java.mdx +++ b/platform-includes/crons/requirements/java.mdx @@ -6,5 +6,5 @@ - Send a monitor configuration from your code as shown below, and Sentry creates the monitor on the first check-in. You can also [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) instead. -- From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn(value = "", upsertMonitorConfig = true)` sends a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Otherwise, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. +- From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` sends a monitor configuration based on the method's `@Scheduled` annotation by default, and Sentry creates the monitor on the first check-in. With `upsertMonitorConfig = false`, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 0bad5abf91be0..99ff9fa098241 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -54,11 +54,11 @@ public class CustomJob { ### Monitor Configuration From `@Scheduled` -From the next Sentry Java SDK release (after `8.59.0`), set `upsertMonitorConfig = true` and `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in, so Sentry creates the monitor, or updates its schedule, from your code: +From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in by default, so Sentry creates the monitor, or updates its schedule, from your code: ```java @Scheduled(cron = "0 0 * * * *") -@SentryCheckIn(value = "", upsertMonitorConfig = true) // 👈 +@SentryCheckIn("") // 👈 void execute() { // your task code } @@ -70,10 +70,12 @@ The schedule is converted like this: - `fixedRate` (including `fixedRateString`, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. `fixedDelay` jobs send no monitor config. - `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. It must be an IANA time zone ID such as `Europe/Vienna`; whole-hour offsets such as `GMT+2` are sent as `Etc/GMT-2`. -Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), cron expressions that set both day-of-month and day-of-week (on Spring 5.3 and later, a day-of-month step such as `0 0 9 */2 * MON` is converted; on older Spring versions, none are), `#5` days of week on Spring 5.3 and later, cron syntax Sentry doesn't support (such as `15W`, `L-3`, or wrap-around ranges like `22-2`), other time zones, periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods without `upsertMonitorConfig = true`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. +Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), cron expressions that set both day-of-month and day-of-week (on Spring 5.3 and later, a day-of-month step such as `0 0 9 */2 * MON` is converted; on older Spring versions, none are), `#5` days of week on Spring 5.3 and later, cron syntax Sentry doesn't support (such as `15W`, `L-3`, or wrap-around ranges like `22-2`), other time zones, periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods with `upsertMonitorConfig = false`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. Sentry only updates the fields that were sent. Margins, max runtime, and thresholds configured in Sentry are kept unless you set defaults for them in `options.cron`, which are sent only with check-ins that carry a monitor configuration. +When you upgrade, monitors that already exist get the schedule and timezone from `@Scheduled` (the JVM's default time zone if `zone` isn't set), overwriting the ones set in Sentry. To keep managing a monitor's schedule in Sentry, for example because its timezone differs from the JVM's, set `@SentryCheckIn(value = "", upsertMonitorConfig = false)`. + ## Heartbeat 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. To start sending heartbeats simply add the `@SentryCheckIn(monitorSlug = "", heartbeat = true)` annotation to the method you want to send heartbeats for. From 6905665a1f65cb697cfbdf60020720274a7e1afe Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 5 Oct 2026 16:30:35 -0700 Subject: [PATCH 08/19] docs(crons): Shorten Spring upsertMonitorConfig opt-out note Co-Authored-By: Claude --- platform-includes/crons/setup/java.spring-boot.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 99ff9fa098241..243937a1c455d 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -74,7 +74,7 @@ Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sen Sentry only updates the fields that were sent. Margins, max runtime, and thresholds configured in Sentry are kept unless you set defaults for them in `options.cron`, which are sent only with check-ins that carry a monitor configuration. -When you upgrade, monitors that already exist get the schedule and timezone from `@Scheduled` (the JVM's default time zone if `zone` isn't set), overwriting the ones set in Sentry. To keep managing a monitor's schedule in Sentry, for example because its timezone differs from the JVM's, set `@SentryCheckIn(value = "", upsertMonitorConfig = false)`. +When you upgrade, monitors that already exist get the schedule and timezone from `@Scheduled` (the JVM's default time zone if `zone` isn't set), overwriting the ones set in Sentry. To keep managing a monitor's schedule in Sentry, set `@SentryCheckIn(value = "", upsertMonitorConfig = false)`. ## Heartbeat From 47378aed7e2c2a03a7bf065046fb419f97f2fb2f Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Tue, 13 Oct 2026 12:05:57 -0700 Subject: [PATCH 09/19] docs(java): Point the monitor config note at releases after 8.60.0 --- platform-includes/crons/requirements/java.mdx | 2 +- platform-includes/crons/setup/java.spring-boot.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/requirements/java.mdx b/platform-includes/crons/requirements/java.mdx index e47f9f562e3ad..20f0a64dddb17 100644 --- a/platform-includes/crons/requirements/java.mdx +++ b/platform-includes/crons/requirements/java.mdx @@ -6,5 +6,5 @@ - Send a monitor configuration from your code as shown below, and Sentry creates the monitor on the first check-in. You can also [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) instead. -- From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` sends a monitor configuration based on the method's `@Scheduled` annotation by default, and Sentry creates the monitor on the first check-in. With `upsertMonitorConfig = false`, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. +- From the next Sentry Java SDK release (after `8.60.0`), `@SentryCheckIn` sends a monitor configuration based on the method's `@Scheduled` annotation by default, and Sentry creates the monitor on the first check-in. With `upsertMonitorConfig = false`, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 243937a1c455d..365f6373df8b1 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -54,7 +54,7 @@ public class CustomJob { ### Monitor Configuration From `@Scheduled` -From the next Sentry Java SDK release (after `8.59.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in by default, so Sentry creates the monitor, or updates its schedule, from your code: +From the next Sentry Java SDK release (after `8.60.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in by default, so Sentry creates the monitor, or updates its schedule, from your code: ```java @Scheduled(cron = "0 0 * * * *") From 87c9f617ba300840212e6aa7127746c8103d44ec Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 16 Oct 2026 18:01:42 -0700 Subject: [PATCH 10/19] docs(crons): Document monitoring all Spring @Scheduled methods Co-Authored-By: Claude --- platform-includes/crons/setup/java.spring-boot.mdx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 365f6373df8b1..db592d9b7a0f9 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -76,6 +76,20 @@ Sentry only updates the fields that were sent. Margins, max runtime, and thresho When you upgrade, monitors that already exist get the schedule and timezone from `@Scheduled` (the JVM's default time zone if `zone` isn't set), overwriting the ones set in Sentry. To keep managing a monitor's schedule in Sentry, set `@SentryCheckIn(value = "", upsertMonitorConfig = false)`. +### Monitor All `@Scheduled` Methods + +From the next Sentry Java SDK release (after `8.60.0`), you can monitor every `@Scheduled` method without adding `@SentryCheckIn` to each one: + +```properties {filename:application.properties} +sentry.monitor-scheduled-tasks=true +# Optional: methods to skip, as ClassName.methodName or a regular expression +sentry.exclude-scheduled-tasks=ReportJobs.sendDailyReport,Internal.* +``` + +Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is sent as described above. Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) still send check-ins, but without a monitor configuration, so create those monitors in Sentry first. + +Methods annotated with `@SentryCheckIn` keep their own slug and settings. Methods on `final` classes and `final` methods can't be monitored this way. + ## Heartbeat 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. To start sending heartbeats simply add the `@SentryCheckIn(monitorSlug = "", heartbeat = true)` annotation to the method you want to send heartbeats for. From b6131a7f895766c22d649c6db2880ff87335dee4 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 19 Oct 2026 17:50:16 -0700 Subject: [PATCH 11/19] docs(crons): Recommend monitoring all Spring @Scheduled methods first Co-Authored-By: Claude --- .../crons/setup/java.spring-boot.mdx | 36 +++++++++++-------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index db592d9b7a0f9..57c5d20fa19db 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -8,7 +8,25 @@ The `@SentryCheckIn` annotation requires `org.aspectj:aspectjweaver` to be prese ## Check-Ins (Recommended) -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). To start sending check-ins simply add the `@SentryCheckIn("")` annotation to the method you want to send check-ins for. +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). + +### Monitor All `@Scheduled` Methods + +We recommend monitoring every `@Scheduled` method. From the next Sentry Java SDK release (after `8.60.0`), you can do this without adding `@SentryCheckIn` to each one: + +```properties {filename:application.properties} +sentry.monitor-scheduled-tasks=true +# Optional: methods to skip, as ClassName.methodName or a regular expression +sentry.exclude-scheduled-tasks=ReportJobs.sendDailyReport,Internal.* +``` + +Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is sent as described in [Monitor Configuration From `@Scheduled`](#monitor-configuration-from-scheduled). Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) still send check-ins, but without a monitor configuration, so create those monitors in Sentry first. + +Methods annotated with `@SentryCheckIn` keep their own slug and settings. Methods on `final` classes and `final` methods can't be monitored this way. + +### Monitor Specific Methods + +To send check-ins for specific methods, add the `@SentryCheckIn("")` annotation to the method you want to send check-ins for. ```java {tabTitle:Java (Spring Boot 3)} {mdExpandTabs} import io.sentry.spring.jakarta.checkin.SentryCheckIn; @@ -52,6 +70,8 @@ public class CustomJob { } ``` +With `sentry.monitor-scheduled-tasks` on, a method with `@SentryCheckIn` is checked in once per run, using the annotation's slug and settings. + ### Monitor Configuration From `@Scheduled` From the next Sentry Java SDK release (after `8.60.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in by default, so Sentry creates the monitor, or updates its schedule, from your code: @@ -76,20 +96,6 @@ Sentry only updates the fields that were sent. Margins, max runtime, and thresho When you upgrade, monitors that already exist get the schedule and timezone from `@Scheduled` (the JVM's default time zone if `zone` isn't set), overwriting the ones set in Sentry. To keep managing a monitor's schedule in Sentry, set `@SentryCheckIn(value = "", upsertMonitorConfig = false)`. -### Monitor All `@Scheduled` Methods - -From the next Sentry Java SDK release (after `8.60.0`), you can monitor every `@Scheduled` method without adding `@SentryCheckIn` to each one: - -```properties {filename:application.properties} -sentry.monitor-scheduled-tasks=true -# Optional: methods to skip, as ClassName.methodName or a regular expression -sentry.exclude-scheduled-tasks=ReportJobs.sendDailyReport,Internal.* -``` - -Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is sent as described above. Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) still send check-ins, but without a monitor configuration, so create those monitors in Sentry first. - -Methods annotated with `@SentryCheckIn` keep their own slug and settings. Methods on `final` classes and `final` methods can't be monitored this way. - ## Heartbeat 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. To start sending heartbeats simply add the `@SentryCheckIn(monitorSlug = "", heartbeat = true)` annotation to the method you want to send heartbeats for. From 39f3abe1c0563516a7bf11be64c467c8092501bb Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 19 Oct 2026 18:04:11 -0700 Subject: [PATCH 12/19] chore: Retrigger Vercel build Co-Authored-By: Claude From 13b829c65b46548c920381d35c177331d4816648 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Tue, 20 Oct 2026 10:50:13 -0700 Subject: [PATCH 13/19] docs(crons): Fix Spring monitor-all version and requirements Co-Authored-By: Claude --- platform-includes/crons/setup/java.spring-boot.mdx | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 57c5d20fa19db..a57ac2d2454c5 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -2,7 +2,7 @@ If you are using [Quartz](http://www.quartz-scheduler.org/), please see -The `@SentryCheckIn` annotation requires `org.aspectj:aspectjweaver` to be present as a dependency in your project. +The `@SentryCheckIn` annotation and `sentry.monitor-scheduled-tasks` require `org.aspectj:aspectjweaver` to be present as a dependency in your project. @@ -12,7 +12,7 @@ Check-in monitoring allows you to track a job's progress by completing two check ### Monitor All `@Scheduled` Methods -We recommend monitoring every `@Scheduled` method. From the next Sentry Java SDK release (after `8.60.0`), you can do this without adding `@SentryCheckIn` to each one: +We recommend monitoring every `@Scheduled` method. From the next Sentry Java SDK release (after `8.61.0`), you can do this without adding `@SentryCheckIn` to each one: ```properties {filename:application.properties} sentry.monitor-scheduled-tasks=true @@ -22,7 +22,7 @@ sentry.exclude-scheduled-tasks=ReportJobs.sendDailyReport,Internal.* Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is sent as described in [Monitor Configuration From `@Scheduled`](#monitor-configuration-from-scheduled). Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) still send check-ins, but without a monitor configuration, so create those monitors in Sentry first. -Methods annotated with `@SentryCheckIn` keep their own slug and settings. Methods on `final` classes and `final` methods can't be monitored this way. +Methods annotated with `@SentryCheckIn` keep their own slug and settings and are checked in once per run. Methods on `final` classes, `final` methods, and reactive or Kotlin `suspend` methods can't be monitored this way. ### Monitor Specific Methods @@ -70,8 +70,6 @@ public class CustomJob { } ``` -With `sentry.monitor-scheduled-tasks` on, a method with `@SentryCheckIn` is checked in once per run, using the annotation's slug and settings. - ### Monitor Configuration From `@Scheduled` From the next Sentry Java SDK release (after `8.60.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in by default, so Sentry creates the monitor, or updates its schedule, from your code: From ae06afc4534ec341e2f9ace4da2c302f1a7e3b95 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Thu, 29 Oct 2026 11:01:52 -0700 Subject: [PATCH 14/19] docs(crons): Spring Boot skips jobs with unsupported schedules when monitoring all jobs --- platform-includes/crons/setup/java.spring-boot.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index a57ac2d2454c5..acf698d1fd285 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -20,7 +20,7 @@ sentry.monitor-scheduled-tasks=true sentry.exclude-scheduled-tasks=ReportJobs.sendDailyReport,Internal.* ``` -Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is sent as described in [Monitor Configuration From `@Scheduled`](#monitor-configuration-from-scheduled). Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) still send check-ins, but without a monitor configuration, so create those monitors in Sentry first. +Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is sent as described in [Monitor Configuration From `@Scheduled`](#monitor-configuration-from-scheduled). Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) aren't monitored. To monitor one, add `@SentryCheckIn` with a slug and create the monitor in Sentry first. Methods annotated with `@SentryCheckIn` keep their own slug and settings and are checked in once per run. Methods on `final` classes, `final` methods, and reactive or Kotlin `suspend` methods can't be monitored this way. From a471fabb740e7bf7dd18172cae6ecf8538af2c51 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Thu, 5 Nov 2026 11:42:53 -0500 Subject: [PATCH 15/19] docs(java): Make the Spring @Scheduled monitor config opt-in @SentryCheckIn sends the schedule only with upsertMonitorConfig = true, so existing monitors aren't changed on upgrade. --- platform-includes/crons/requirements/java.mdx | 2 +- platform-includes/crons/setup/java.spring-boot.mdx | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/platform-includes/crons/requirements/java.mdx b/platform-includes/crons/requirements/java.mdx index 20f0a64dddb17..cbfc126d35688 100644 --- a/platform-includes/crons/requirements/java.mdx +++ b/platform-includes/crons/requirements/java.mdx @@ -6,5 +6,5 @@ - Send a monitor configuration from your code as shown below, and Sentry creates the monitor on the first check-in. You can also [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) instead. -- From the next Sentry Java SDK release (after `8.60.0`), `@SentryCheckIn` sends a monitor configuration based on the method's `@Scheduled` annotation by default, and Sentry creates the monitor on the first check-in. With `upsertMonitorConfig = false`, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. +- From the next Sentry Java SDK release (after `8.63.0`), `@SentryCheckIn(upsertMonitorConfig = true)` sends a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Without it, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 365f6373df8b1..d774d3a24c1ae 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -54,11 +54,11 @@ public class CustomJob { ### Monitor Configuration From `@Scheduled` -From the next Sentry Java SDK release (after `8.60.0`), `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in by default, so Sentry creates the monitor, or updates its schedule, from your code: +From the next Sentry Java SDK release (after `8.63.0`), set `upsertMonitorConfig = true` and `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in, so Sentry creates the monitor, or updates its schedule, from your code: ```java @Scheduled(cron = "0 0 * * * *") -@SentryCheckIn("") // 👈 +@SentryCheckIn(value = "", upsertMonitorConfig = true) // 👈 void execute() { // your task code } @@ -66,15 +66,15 @@ void execute() { The schedule is converted like this: -- `cron`: a Spring cron expression with a fixed seconds field (for example `0 0 * * * *`) is sent as a crontab schedule without the seconds. Spring macros such as `@hourly` and `@daily` are supported. +- `cron`: a Spring cron expression with a fixed seconds field (for example `0 0 * * * *`) is sent as a crontab schedule without the seconds. If the seconds field isn't `0`, a check-in margin of 2 minutes is sent too, since the job checks in up to 59 seconds after the minute Sentry expects. This replaces a margin set in Sentry; set a larger `options.cron` default check-in margin to keep it. Spring macros such as `@hourly` and `@daily` are supported. - `fixedRate` (including `fixedRateString`, such as `"5m"` or `"PT5M"`, and `timeUnit`): sent as an interval schedule when the period is a whole number of minutes. `fixedDelay` jobs send no monitor config. - `zone`: sent as the monitor's timezone for cron schedules. Without `zone`, the JVM's default time zone is sent, since that's where Spring runs the job. It must be an IANA time zone ID such as `Europe/Vienna`; whole-hour offsets such as `GMT+2` are sent as `Etc/GMT-2`. -Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), cron expressions that set both day-of-month and day-of-week (on Spring 5.3 and later, a day-of-month step such as `0 0 9 */2 * MON` is converted; on older Spring versions, none are), `#5` days of week on Spring 5.3 and later, cron syntax Sentry doesn't support (such as `15W`, `L-3`, or wrap-around ranges like `22-2`), other time zones, periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods with `upsertMonitorConfig = false`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. +Placeholders such as `${app.cleanup.cron}` are resolved. No configuration is sent for cron expressions with variable seconds (for example `*/30 * * * * *`), cron expressions that set both day-of-month and day-of-week (on Spring 5.3 and later, a day-of-month step such as `0 0 9 */2 * MON` is converted; on older Spring versions, none are), `#5` days of week on Spring 5.3 and later, cron syntax Sentry doesn't support (such as `15W`, `L-3`, or wrap-around ranges like `22-2`), other time zones, periods that aren't whole minutes, methods with more than one `@Scheduled`, or heartbeat check-ins. For those, for methods without `upsertMonitorConfig = true`, and for older SDK versions, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first. Sentry only updates the fields that were sent. Margins, max runtime, and thresholds configured in Sentry are kept unless you set defaults for them in `options.cron`, which are sent only with check-ins that carry a monitor configuration. -When you upgrade, monitors that already exist get the schedule and timezone from `@Scheduled` (the JVM's default time zone if `zone` isn't set), overwriting the ones set in Sentry. To keep managing a monitor's schedule in Sentry, set `@SentryCheckIn(value = "", upsertMonitorConfig = false)`. +When you turn on `upsertMonitorConfig` for a monitor that already exists, it gets the schedule and timezone from `@Scheduled` (the JVM's default time zone if `zone` isn't set), overwriting the ones set in Sentry. ## Heartbeat From 024bd37794c20cffd1d65847a5a5952c7f4bf497 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Thu, 5 Nov 2026 11:43:25 -0500 Subject: [PATCH 16/19] docs(java): Note that monitoring all @Scheduled methods always sends the schedule @SentryCheckIn only sends it with upsertMonitorConfig = true, while sentry.monitor-scheduled-tasks needs it to create the monitors. --- platform-includes/crons/requirements/java.mdx | 2 +- platform-includes/crons/setup/java.spring-boot.mdx | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/platform-includes/crons/requirements/java.mdx b/platform-includes/crons/requirements/java.mdx index cbfc126d35688..e08413aabd204 100644 --- a/platform-includes/crons/requirements/java.mdx +++ b/platform-includes/crons/requirements/java.mdx @@ -6,5 +6,5 @@ - Send a monitor configuration from your code as shown below, and Sentry creates the monitor on the first check-in. You can also [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) instead. -- From the next Sentry Java SDK release (after `8.63.0`), `@SentryCheckIn(upsertMonitorConfig = true)` sends a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Without it, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. +- From the next Sentry Java SDK release (after `8.63.0`), `sentry.monitor-scheduled-tasks=true` and `@SentryCheckIn(upsertMonitorConfig = true)` send a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Without either, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index b6446b259bf8e..17a416b690381 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -12,7 +12,7 @@ Check-in monitoring allows you to track a job's progress by completing two check ### Monitor All `@Scheduled` Methods -We recommend monitoring every `@Scheduled` method. From the next Sentry Java SDK release (after `8.61.0`), you can do this without adding `@SentryCheckIn` to each one: +We recommend monitoring every `@Scheduled` method. From the next Sentry Java SDK release (after `8.63.0`), you can do this without adding `@SentryCheckIn` to each one: ```properties {filename:application.properties} sentry.monitor-scheduled-tasks=true @@ -20,9 +20,9 @@ sentry.monitor-scheduled-tasks=true sentry.exclude-scheduled-tasks=ReportJobs.sendDailyReport,Internal.* ``` -Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is sent as described in [Monitor Configuration From `@Scheduled`](#monitor-configuration-from-scheduled). Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) aren't monitored. To monitor one, add `@SentryCheckIn` with a slug and create the monitor in Sentry first. +Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is always sent, as described in [Monitor Configuration From `@Scheduled`](#monitor-configuration-from-scheduled), so Sentry creates each monitor on its first check-in. Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) aren't monitored. To monitor one, add `@SentryCheckIn` with a slug and create the monitor in Sentry first. -Methods annotated with `@SentryCheckIn` keep their own slug and settings and are checked in once per run. Methods on `final` classes, `final` methods, and reactive or Kotlin `suspend` methods can't be monitored this way. +Methods annotated with `@SentryCheckIn` keep their own slug and settings, including `upsertMonitorConfig`, and are checked in once per run. Methods on `final` classes, `final` methods, and reactive or Kotlin `suspend` methods can't be monitored this way. ### Monitor Specific Methods From ecd0f51150654939230a299cae43879612a5f80f Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Wed, 11 Nov 2026 09:23:49 -0800 Subject: [PATCH 17/19] docs(crons): Name 8.64.0 as the first Java SDK version with Spring monitor config --- platform-includes/crons/requirements/java.mdx | 2 +- platform-includes/crons/setup/java.spring-boot.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/requirements/java.mdx b/platform-includes/crons/requirements/java.mdx index cbfc126d35688..510d0678eb16c 100644 --- a/platform-includes/crons/requirements/java.mdx +++ b/platform-includes/crons/requirements/java.mdx @@ -6,5 +6,5 @@ - Send a monitor configuration from your code as shown below, and Sentry creates the monitor on the first check-in. You can also [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) instead. -- From the next Sentry Java SDK release (after `8.63.0`), `@SentryCheckIn(upsertMonitorConfig = true)` sends a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Without it, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. +- From Sentry Java SDK version `8.64.0`, `@SentryCheckIn(upsertMonitorConfig = true)` sends a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Without it, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index d774d3a24c1ae..b48a78d756b9d 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -54,7 +54,7 @@ public class CustomJob { ### Monitor Configuration From `@Scheduled` -From the next Sentry Java SDK release (after `8.63.0`), set `upsertMonitorConfig = true` and `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in, so Sentry creates the monitor, or updates its schedule, from your code: +From Sentry Java SDK version `8.64.0`, set `upsertMonitorConfig = true` and `@SentryCheckIn` reads the method's `@Scheduled` annotation and sends a monitor configuration with the in-progress check-in, so Sentry creates the monitor, or updates its schedule, from your code: ```java @Scheduled(cron = "0 0 * * * *") From e09b4d06ca43163d09fb183372421e49daf2c98f Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Wed, 11 Nov 2026 09:24:02 -0800 Subject: [PATCH 18/19] docs(crons): Name 8.64.0 as the first Java SDK version with monitor-scheduled-tasks --- platform-includes/crons/requirements/java.mdx | 2 +- platform-includes/crons/setup/java.spring-boot.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/requirements/java.mdx b/platform-includes/crons/requirements/java.mdx index e08413aabd204..654d75f626cbc 100644 --- a/platform-includes/crons/requirements/java.mdx +++ b/platform-includes/crons/requirements/java.mdx @@ -6,5 +6,5 @@ - Send a monitor configuration from your code as shown below, and Sentry creates the monitor on the first check-in. You can also [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) instead. -- From the next Sentry Java SDK release (after `8.63.0`), `sentry.monitor-scheduled-tasks=true` and `@SentryCheckIn(upsertMonitorConfig = true)` send a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Without either, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. +- From Sentry Java SDK version `8.64.0`, `sentry.monitor-scheduled-tasks=true` and `@SentryCheckIn(upsertMonitorConfig = true)` send a monitor configuration based on the method's `@Scheduled` annotation, and Sentry creates the monitor on the first check-in. Without either, on older SDK versions, or for schedules that can't be converted, [create the monitor in Sentry](https://sentry.io/issues/alerts/new/crons/) first, because Sentry drops check-ins for a slug that has no monitor. diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 6d8c77a88005c..8eef48e5f8b70 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -12,7 +12,7 @@ Check-in monitoring allows you to track a job's progress by completing two check ### Monitor All `@Scheduled` Methods -We recommend monitoring every `@Scheduled` method. From the next Sentry Java SDK release (after `8.63.0`), you can do this without adding `@SentryCheckIn` to each one: +We recommend monitoring every `@Scheduled` method. From Sentry Java SDK version `8.64.0`, you can do this without adding `@SentryCheckIn` to each one: ```properties {filename:application.properties} sentry.monitor-scheduled-tasks=true From c25f5c404738872f5a9bb8c9f48eb604cbeb90f2 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Wed, 11 Nov 2026 09:41:39 -0800 Subject: [PATCH 19/19] docs(crons): Note that private and static @Scheduled methods aren't monitored --- platform-includes/crons/setup/java.spring-boot.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-includes/crons/setup/java.spring-boot.mdx b/platform-includes/crons/setup/java.spring-boot.mdx index 8eef48e5f8b70..6f966ecac4982 100644 --- a/platform-includes/crons/setup/java.spring-boot.mdx +++ b/platform-includes/crons/setup/java.spring-boot.mdx @@ -22,7 +22,7 @@ sentry.exclude-scheduled-tasks=ReportJobs.sendDailyReport,Internal.* Each method gets a monitor slug built from its class and method name, for example `report-jobs-send-daily-report` for `ReportJobs.sendDailyReport`. Nested classes include the outer class name (`Outer.Inner.method`), and slugs longer than 50 characters are shortened with a hash suffix. The schedule is always sent, as described in [Monitor Configuration From `@Scheduled`](#monitor-configuration-from-scheduled), so Sentry creates each monitor on its first check-in. Methods with schedules that can't be expressed in the Crons schedule format (for example, a `fixedDelay` job) aren't monitored. To monitor one, add `@SentryCheckIn` with a slug and create the monitor in Sentry first. -Methods annotated with `@SentryCheckIn` keep their own slug and settings, including `upsertMonitorConfig`, and are checked in once per run. Methods on `final` classes, `final` methods, and reactive or Kotlin `suspend` methods can't be monitored this way. +Methods annotated with `@SentryCheckIn` keep their own slug and settings, including `upsertMonitorConfig`, and are checked in once per run. Methods on `final` classes, `final`, `private`, and `static` methods, and reactive or Kotlin `suspend` methods can't be monitored this way. ### Monitor Specific Methods