From 36d3b802e04e14408b013334b32e43fbcca6f754 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 2 Oct 2026 12:43:20 -0700 Subject: [PATCH 1/8] 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 13baa55a15e561..ad8b8a3e666978 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 a711aa8b2bcdb9..02a2101791ae93 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 2/8] 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 02a2101791ae93..9dbe943a2234cb 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 3/8] 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 ad8b8a3e666978..1cdbe149330706 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 9dbe943a2234cb..ea008498d67156 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 4/8] 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 ea008498d67156..9400792d7d9f8d 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 5/8] 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 9400792d7d9f8d..76550c642d0086 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 6/8] 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 76550c642d0086..0bad5abf91be0c 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 7/8] 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 1cdbe149330706..e47f9f562e3ad7 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 0bad5abf91be0c..99ff9fa0982414 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 8/8] 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 99ff9fa0982414..243937a1c455d3 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