From 0121f81e0c30dc127c2198e4939a40789be38985 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 2 Oct 2026 17:18:19 -0700 Subject: [PATCH 01/11] docs(crons): Add rufus-scheduler setup for Ruby Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 37 ++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index c199d34313348b..6b995c2752748f 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -56,6 +56,43 @@ sentry_monitor_check_ins monitor_config: Sentry::Cron::MonitorConfig.from_interv sentry_monitor_check_ins monitor_config: Sentry::Cron::MonitorConfig.from_crontab('5 * * * *') ``` +### rufus-scheduler + + + +The rufus-scheduler integration ships in the next release of `sentry-ruby`. + + + +If you're using `rufus-scheduler`, enable the `:rufus_scheduler` patch to capture check-ins for `cron`, `every`, and `interval` jobs: + +```rb +Sentry.init do |config| + config.enabled_patches += [:rufus_scheduler] +end +``` + +```rb +scheduler = Rufus::Scheduler.new + +scheduler.cron '0 9 * * 1-5', name: 'daily-report' do + # do stuff +end + +scheduler.every '10m', name: 'sync-accounts' do + # do stuff +end + +# skip a job +scheduler.every '1m', sentry_monitor: false do + # do stuff +end +``` + +The monitor slug comes from the job's `name` option. Without a name, the SDK falls back to the handler class name or to the block's file and line, which change when the code moves. Set `name` on every job you monitor. + +Sentry creates the monitor from `cron` jobs and from `every` jobs whose frequency is a whole number of minutes, hours, or days. `interval` jobs wait a fixed time after each run ends, so they don't have a fixed schedule. For those, and for cron lines Sentry can't read the same way (for example `L`, `#`, or sub-minute seconds), the SDK sends check-ins without a monitor config, and you need to create the monitor in Sentry with the same slug. One-off `in` and `at` jobs are not monitored, and jobs scheduled by `sidekiq-scheduler` are left to the `:sidekiq_scheduler` patch. + ## Manual Setup If you're using `Clockwork` or `Whenever`, you'll need to instrument your jobs From 16f505ddd983761b4e4deb37fd364ce83362b7cc Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 5 Oct 2026 12:17:31 -0700 Subject: [PATCH 02/11] docs(crons): Update rufus-scheduler slug and time zone notes Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index 6b995c2752748f..db366261b404f4 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -89,9 +89,9 @@ scheduler.every '1m', sentry_monitor: false do end ``` -The monitor slug comes from the job's `name` option. Without a name, the SDK falls back to the handler class name or to the block's file and line, which change when the code moves. Set `name` on every job you monitor. +The monitor slug comes from the job's `name` option, or from the handler's class or method name when you pass one instead of a block. Blocks without a `name` aren't monitored, so set `name` on every block you want to monitor. -Sentry creates the monitor from `cron` jobs and from `every` jobs whose frequency is a whole number of minutes, hours, or days. `interval` jobs wait a fixed time after each run ends, so they don't have a fixed schedule. For those, and for cron lines Sentry can't read the same way (for example `L`, `#`, or sub-minute seconds), the SDK sends check-ins without a monitor config, and you need to create the monitor in Sentry with the same slug. One-off `in` and `at` jobs are not monitored, and jobs scheduled by `sidekiq-scheduler` are left to the `:sidekiq_scheduler` patch. +Sentry creates the monitor from `cron` jobs and from `every` jobs whose frequency is a whole number of minutes, hours, or days. `interval` jobs wait a fixed time after each run ends, so they don't have a fixed schedule. For those, and for cron lines Sentry can't read the same way (for example `L`, `#`, or sub-minute seconds), the SDK sends check-ins without a monitor config, and you need to create the monitor in Sentry with the same slug. The same applies when the job's time zone isn't an IANA name, such as `Europe/Vienna`: offsets like `+05:30` aren't sent. One-off `in` and `at` jobs are not monitored, and jobs scheduled by `sidekiq-scheduler` are left to the `:sidekiq_scheduler` patch. ## Manual Setup From 65f4e573bfa3327a8cebef7395bd044c8b8ca74c Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 5 Oct 2026 12:17:40 -0700 Subject: [PATCH 03/11] docs(crons): Clarify rufus-scheduler time zone note Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index db366261b404f4..b44f4ba480c33e 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -91,7 +91,7 @@ end The monitor slug comes from the job's `name` option, or from the handler's class or method name when you pass one instead of a block. Blocks without a `name` aren't monitored, so set `name` on every block you want to monitor. -Sentry creates the monitor from `cron` jobs and from `every` jobs whose frequency is a whole number of minutes, hours, or days. `interval` jobs wait a fixed time after each run ends, so they don't have a fixed schedule. For those, and for cron lines Sentry can't read the same way (for example `L`, `#`, or sub-minute seconds), the SDK sends check-ins without a monitor config, and you need to create the monitor in Sentry with the same slug. The same applies when the job's time zone isn't an IANA name, such as `Europe/Vienna`: offsets like `+05:30` aren't sent. One-off `in` and `at` jobs are not monitored, and jobs scheduled by `sidekiq-scheduler` are left to the `:sidekiq_scheduler` patch. +Sentry creates the monitor from `cron` jobs and from `every` jobs whose frequency is a whole number of minutes, hours, or days. `interval` jobs wait a fixed time after each run ends, so they don't have a fixed schedule. For those, and for cron lines Sentry can't read the same way (for example `L`, `#`, or sub-minute seconds), the SDK sends check-ins without a monitor config, and you need to create the monitor in Sentry with the same slug. The same applies when the job's time zone is an offset like `+05:30` rather than an IANA name like `Europe/Vienna`. One-off `in` and `at` jobs are not monitored, and jobs scheduled by `sidekiq-scheduler` are left to the `:sidekiq_scheduler` patch. ## Manual Setup From 6c2693dc91240c29a4bdf618eb8a07357f494b99 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 16 Oct 2026 15:41:10 -0700 Subject: [PATCH 04/11] docs(crons): Add Solid Queue setup for Ruby Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 35 ++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index b44f4ba480c33e..495f09d6beadd0 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -93,6 +93,41 @@ The monitor slug comes from the job's `name` option, or from the handler's class Sentry creates the monitor from `cron` jobs and from `every` jobs whose frequency is a whole number of minutes, hours, or days. `interval` jobs wait a fixed time after each run ends, so they don't have a fixed schedule. For those, and for cron lines Sentry can't read the same way (for example `L`, `#`, or sub-minute seconds), the SDK sends check-ins without a monitor config, and you need to create the monitor in Sentry with the same slug. The same applies when the job's time zone is an offset like `+05:30` rather than an IANA name like `Europe/Vienna`. One-off `in` and `at` jobs are not monitored, and jobs scheduled by `sidekiq-scheduler` are left to the `:sidekiq_scheduler` patch. +### Solid Queue + + + +The Solid Queue integration ships in the next release of `sentry-rails`. + + + +If you're using Solid Queue recurring tasks, enable the `:solid_queue_recurring` patch to capture check-ins for every task in `config/recurring.yml`, as well as dynamic tasks: + +```rb +Sentry.init do |config| + config.enabled_patches << :solid_queue_recurring +end +``` + +```yaml {filename:config/recurring.yml} +production: + nightly_report: + class: ReportJob + args: [nightly] + schedule: "0 2 * * * America/New_York" + weekly_report: + class: ReportJob + args: [weekly] + schedule: every monday at 9am + clear_cache: + command: "Rails.cache.clear" + schedule: every hour +``` + +The monitor slug is the task key, so this example creates three monitors: `nightly_report`, `weekly_report`, and `clear_cache`. Each task gets its own monitor, even when tasks share a job class. Both `class` and `command` tasks are monitored. + +Sentry creates and updates each monitor from the task's schedule and time zone. Schedules that can't be expressed in the Crons schedule format, such as a task that runs every 10 seconds, still send check-ins, but without a monitor config. Create those monitors in Sentry first, using the same slug. Jobs that already call `sentry_monitor_check_ins` are left as they are. + ## Manual Setup If you're using `Clockwork` or `Whenever`, you'll need to instrument your jobs From 8ece47e81886342d4fe5777f32f55fe9b1de18e1 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 16 Oct 2026 16:05:49 -0700 Subject: [PATCH 05/11] docs(crons): Document excluding Solid Queue recurring tasks Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index 495f09d6beadd0..0a8116edbf7609 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -128,6 +128,15 @@ The monitor slug is the task key, so this example creates three monitors: `night Sentry creates and updates each monitor from the task's schedule and time zone. Schedules that can't be expressed in the Crons schedule format, such as a task that runs every 10 seconds, still send check-ins, but without a monitor config. Create those monitors in Sentry first, using the same slug. Jobs that already call `sentry_monitor_check_ins` are left as they are. +To skip tasks, list their keys in `config.rails.solid_queue_exclude_recurring_tasks`. Strings match a task key exactly, and regular expressions are matched against it: + +```rb +Sentry.init do |config| + config.enabled_patches << :solid_queue_recurring + config.rails.solid_queue_exclude_recurring_tasks = ["clear_cache", /^tmp_/] +end +``` + ## Manual Setup If you're using `Clockwork` or `Whenever`, you'll need to instrument your jobs From f07ff336578827416557c1990693654110cdb928 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 16 Oct 2026 16:47:47 -0700 Subject: [PATCH 06/11] docs(crons): Use a sub-minute example for unsupported rufus schedules The SDK now converts `L` and `#` cron fields, so they no longer belong in the list of schedules sent without a monitor config. Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index b44f4ba480c33e..63d6a285f06fe4 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -91,7 +91,7 @@ end The monitor slug comes from the job's `name` option, or from the handler's class or method name when you pass one instead of a block. Blocks without a `name` aren't monitored, so set `name` on every block you want to monitor. -Sentry creates the monitor from `cron` jobs and from `every` jobs whose frequency is a whole number of minutes, hours, or days. `interval` jobs wait a fixed time after each run ends, so they don't have a fixed schedule. For those, and for cron lines Sentry can't read the same way (for example `L`, `#`, or sub-minute seconds), the SDK sends check-ins without a monitor config, and you need to create the monitor in Sentry with the same slug. The same applies when the job's time zone is an offset like `+05:30` rather than an IANA name like `Europe/Vienna`. One-off `in` and `at` jobs are not monitored, and jobs scheduled by `sidekiq-scheduler` are left to the `:sidekiq_scheduler` patch. +Sentry creates the monitor from `cron` jobs and from `every` jobs whose frequency is a whole number of minutes, hours, or days. `interval` jobs wait a fixed time after each run ends, so they don't have a fixed schedule. For those, and for schedules that can't be expressed in the Crons schedule format, such as a job that runs every 10 seconds, the SDK sends check-ins without a monitor config, and you need to create the monitor in Sentry with the same slug. The same applies when the job's time zone is an offset like `+05:30` rather than an IANA name like `Europe/Vienna`. One-off `in` and `at` jobs are not monitored, and jobs scheduled by `sidekiq-scheduler` are left to the `:sidekiq_scheduler` patch. ## Manual Setup From a90c2ff64a5cba841c08d535136972355bf26f68 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Fri, 16 Oct 2026 16:47:54 -0700 Subject: [PATCH 07/11] docs(crons): Use += for the Solid Queue enabled_patches examples Matches the other enabled_patches examples on the page. Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index 0a8116edbf7609..86d4ab3bb65b39 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -105,7 +105,7 @@ If you're using Solid Queue recurring tasks, enable the `:solid_queue_recurring` ```rb Sentry.init do |config| - config.enabled_patches << :solid_queue_recurring + config.enabled_patches += [:solid_queue_recurring] end ``` @@ -132,7 +132,7 @@ To skip tasks, list their keys in `config.rails.solid_queue_exclude_recurring_ta ```rb Sentry.init do |config| - config.enabled_patches << :solid_queue_recurring + config.enabled_patches += [:solid_queue_recurring] config.rails.solid_queue_exclude_recurring_tasks = ["clear_cache", /^tmp_/] end ``` From 16312f46c3789487b20d35cfec7e892901166d89 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 19 Oct 2026 16:18:11 -0700 Subject: [PATCH 08/11] docs(crons): Add resque-scheduler setup for Ruby Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 39 ++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index 86d4ab3bb65b39..99bfd0cfb700fc 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -137,6 +137,45 @@ Sentry.init do |config| end ``` +### resque-scheduler + + + +The resque-scheduler integration ships in the next release of `sentry-resque`. + + + +If you're using `resque-scheduler`, enable the `:resque_scheduler` patch to capture check-ins for every `cron` and `every` schedule, including dynamic schedules: + +```rb +Sentry.init do |config| + config.enabled_patches += [:resque_scheduler] +end +``` + +```yaml {filename:config/resque_schedule.yml} +nightly_report: + cron: "0 2 * * * America/New_York" + class: ReportJob + args: nightly +sync_accounts: + every: 10m + class: SyncAccountsJob +``` + +The monitor slug is the schedule name, so this example creates two monitors: `nightly_report` and `sync_accounts`. Each schedule gets its own monitor, even when schedules share a job class. + +Sentry creates and updates each monitor from the schedule and its time zone. Schedules that can't be expressed in the Crons schedule format, such as a job that runs every 10 seconds, still send check-ins, but without a monitor config. Create those monitors in Sentry first, using the same slug. + +To skip schedules, list their names in `config.resque.exclude_scheduled_jobs`. Strings match a schedule name exactly, and regular expressions are matched against it: + +```rb +Sentry.init do |config| + config.enabled_patches += [:resque_scheduler] + config.resque.exclude_scheduled_jobs = ["clear_cache", /^tmp_/] +end +``` + ## Manual Setup If you're using `Clockwork` or `Whenever`, you'll need to instrument your jobs From e8ad9111c14c109c6852aef0aa83ada6c0f2a6de Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Mon, 19 Oct 2026 16:18:31 -0700 Subject: [PATCH 09/11] docs(crons): Add GoodJob setup for Ruby Co-Authored-By: Claude --- platform-includes/crons/setup/ruby.mdx | 45 ++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index 99bfd0cfb700fc..a04e883366a2b9 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -137,6 +137,51 @@ Sentry.init do |config| end ``` +### GoodJob + + + +The GoodJob integration ships in the next release of `sentry-rails`. + + + +If you're using GoodJob cron, enable the `:good_job_cron` patch to capture check-ins for every entry in `config.good_job.cron`: + +```rb +Sentry.init do |config| + config.enabled_patches += [:good_job_cron] +end +``` + +```rb {filename:config/application.rb} +config.good_job.enable_cron = true +config.good_job.cron = { + nightly_report: { + cron: "0 2 * * * America/New_York", + class: "ReportJob", + args: ["nightly"], + }, + weekly_report: { + cron: "every monday at 9am", + class: "ReportJob", + args: ["weekly"], + }, +} +``` + +The monitor slug is the cron key, so this example creates two monitors: `nightly_report` and `weekly_report`. Each entry gets its own monitor, even when entries share a job class. + +Sentry creates and updates each monitor from the entry's schedule and time zone. Schedules that can't be expressed in the Crons schedule format, such as a job that runs every 10 seconds, and entries whose `cron` is a proc still send check-ins, but without a monitor config. Create those monitors in Sentry first, using the same slug. Jobs that already call `sentry_monitor_check_ins` are left as they are. + +To skip entries, list their keys in `config.rails.good_job_exclude_cron_jobs`. Strings and symbols match a cron key exactly, and regular expressions are matched against it: + +```rb +Sentry.init do |config| + config.enabled_patches += [:good_job_cron] + config.rails.good_job_exclude_cron_jobs = [:clear_cache, /^tmp_/] +end +``` + ### resque-scheduler From 09f8ce44ff4c55c294edb708ca66ba6864c08586 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Thu, 29 Oct 2026 11:01:47 -0700 Subject: [PATCH 10/11] docs(ruby): Unsupported GoodJob cron schedules aren't monitored --- platform-includes/crons/setup/ruby.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index a80cb1e4441ea9..5cd87a0fa5c930 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -171,7 +171,7 @@ config.good_job.cron = { The monitor slug is the cron key, so this example creates two monitors: `nightly_report` and `weekly_report`. Each entry gets its own monitor, even when entries share a job class. -Sentry creates and updates each monitor from the entry's schedule and time zone. Schedules that can't be expressed in the Crons schedule format, such as a job that runs every 10 seconds, and entries whose `cron` is a proc still send check-ins, but without a monitor config. Create those monitors in Sentry first, using the same slug. Jobs that already call `sentry_monitor_check_ins` are left as they are. +Sentry creates and updates each monitor from the entry's schedule and time zone. Schedules that can't be expressed in the Crons schedule format, such as a job that runs every 10 seconds, and entries whose `cron` is a proc aren't monitored. Jobs that already call `sentry_monitor_check_ins` are left as they are. To skip entries, list their keys in `config.rails.good_job_exclude_cron_jobs`. Strings and symbols match a cron key exactly, and regular expressions are matched against it: From 2076dfa5159b85043ac242aa17ff346d06f4ec98 Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Tue, 3 Nov 2026 15:25:09 -0500 Subject: [PATCH 11/11] docs(crons): Remove resque-scheduler setup from GoodJob PR --- platform-includes/crons/setup/ruby.mdx | 39 -------------------------- 1 file changed, 39 deletions(-) diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx index 5cd87a0fa5c930..e5c7558d71f987 100644 --- a/platform-includes/crons/setup/ruby.mdx +++ b/platform-includes/crons/setup/ruby.mdx @@ -182,45 +182,6 @@ Sentry.init do |config| end ``` -### resque-scheduler - - - -The resque-scheduler integration ships in the next release of `sentry-resque`. - - - -If you're using `resque-scheduler`, enable the `:resque_scheduler` patch to capture check-ins for every `cron` and `every` schedule, including dynamic schedules: - -```rb -Sentry.init do |config| - config.enabled_patches += [:resque_scheduler] -end -``` - -```yaml {filename:config/resque_schedule.yml} -nightly_report: - cron: "0 2 * * * America/New_York" - class: ReportJob - args: nightly -sync_accounts: - every: 10m - class: SyncAccountsJob -``` - -The monitor slug is the schedule name, so this example creates two monitors: `nightly_report` and `sync_accounts`. Each schedule gets its own monitor, even when schedules share a job class. - -Sentry creates and updates each monitor from the schedule and its time zone. Schedules that can't be expressed in the Crons schedule format, such as a job that runs every 10 seconds, still send check-ins, but without a monitor config. Create those monitors in Sentry first, using the same slug. - -To skip schedules, list their names in `config.resque.exclude_scheduled_jobs`. Strings match a schedule name exactly, and regular expressions are matched against it: - -```rb -Sentry.init do |config| - config.enabled_patches += [:resque_scheduler] - config.resque.exclude_scheduled_jobs = ["clear_cache", /^tmp_/] -end -``` - ## Manual Setup If you're using `Clockwork` or `Whenever`, you'll need to instrument your jobs