diff --git a/platform-includes/crons/setup/ruby.mdx b/platform-includes/crons/setup/ruby.mdx
index c199d34313348b..e5c7558d71f987 100644
--- a/platform-includes/crons/setup/ruby.mdx
+++ b/platform-includes/crons/setup/ruby.mdx
@@ -56,6 +56,132 @@ 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
+
+<Alert>
+
+The rufus-scheduler integration ships in the next release of `sentry-ruby`.
+
+</Alert>
+
+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, 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 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.
+
+### Solid Queue
+
+<Alert>
+
+The Solid Queue integration ships in the next release of `sentry-rails`.
+
+</Alert>
+
+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.
+
+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
+```
+
+### GoodJob
+
+<Alert>
+
+The GoodJob integration ships in the next release of `sentry-rails`.
+
+</Alert>
+
+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 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:
+
+```rb
+Sentry.init do |config|
+  config.enabled_patches += [:good_job_cron]
+  config.rails.good_job_exclude_cron_jobs = [:clear_cache, /^tmp_/]
+end
+```
+
 ## Manual Setup
 
 If you're using `Clockwork` or `Whenever`, you'll need to instrument your jobs