feat(nestjs): Derive SentryCron monitor config from @Cron by wedamija · Pull Request #25013 · getsentry/sentry-javascript

wedamija · 2026-10-02T19:43:15Z

Part of a series adding automatic Crons monitoring for the most-used job schedulers in each SDK. Check-ins for a monitor that doesn't exist yet are dropped, so today each monitor has to be created by hand with its schedule copied from the code. Sending the job's schedule as the monitor config lets Sentry create the monitor and keep it in sync.

@SentryCron now sends the schedule and time zone of the method's @Cron() decorator with its check-ins, so Sentry creates the monitor on the first run. It's on by default; pass fromCronDecorator: false to send no config. A config with its own schedule is used as is. Monitors created this way are billed, and their schedule and time zone are overwritten from @Cron() on each check-in.

@Cron('0 30 9 * * 1-5', { timeZone: 'Europe/Vienna' })
@SentryCron('daily-report', { checkinMargin: 2 })
async dailyReport() {}

Without a timeZone, the server's local time zone is sent. Schedules Sentry would read differently from @nestjs/schedule (sub-minute, numeric months, some day-field combinations, fixed UTC offsets) check in without a config.

Docs: getsentry/sentry-docs#19782

When `@SentryCron` is used without a monitor config, read the schedule and time zone from the `@Cron()` decorator of `@nestjs/schedule` on the same method. Check-ins then carry a monitor config, so Sentry creates the monitor on the first run instead of dropping the check-ins. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Only read the `@Cron()` schedule when `@SentryCron` gets `{ fromCronDecorator: true }`, so existing usage keeps sending check-ins without a monitor config. Other monitor settings passed alongside the flag are kept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`@SentryCron` now sends the schedule of the method's `@Cron()` decorator unless it gets a monitor config with a schedule. Other monitor settings can still be passed and are merged in, and `fromCronDecorator: false` turns this off. When `@Cron()` has no `timeZone`, the job runs in the server's local time zone, so that zone is sent instead of leaving Sentry to assume UTC. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`@Cron()` presets are now sent: the ones Sentry accepts as is, and `@midnight`, `@minutely`, `@weekdays` and `@weekends` as crontabs. When no schedule can be derived but monitor settings were passed, a debug warning says no monitor config is sent. The settings type now rejects `schedule` and `timezone`, and a full monitor config rejects `fromCronDecorator`, so mixed objects no longer drop fields silently. Adds an E2E case for a disabled `@Cron()` job triggered through an endpoint. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Skip numeric months (cron 2.x counts from 0), day-of-month/day-of-week combinations Sentry would AND, and time zones Sentry rejects. Clarify the warning when fromCronDecorator is false. Co-Authored-By: Claude <noreply@anthropic.com>

@midnight

Allow month steps like */3 (CronExpression.EVERY_QUARTER), still skipping month numbers. Drop the @midnight and @annually presets, which cron rejects. Skip full day ranges like 1-31 when the other day field is set, and send the canonical time zone name. Co-Authored-By: Claude <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8cd5e98. Configure here.}

Co-Authored-By: Claude <noreply@anthropic.com>

github-actions · 2026-10-07T10:16:31Z