Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
126 changes: 126 additions & 0 deletions platform-includes/crons/setup/ruby.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading