Skip to content

feat(nestjs): Derive SentryCron monitor config from @Cron - #25013

Open
wedamija wants to merge 5 commits into
developfrom
danf/nestjs-cron-config
Open

wedamija wants to merge 5 commits into
developfrom
danf/nestjs-cron-config

Conversation

@wedamija

@wedamija wedamija commented Oct 2, 2026 •

Copy link
Copy Markdown
Member

@Cron is NestJS's own scheduling decorator, so users adding @SentryCron already have the schedule on the method. Sentry only creates a monitor from a check-in that carries a config, so @SentryCron('my-job') now sends the @Cron schedule and Sentry creates the monitor on the first run.

  • Other settings (checkinMargin, maxRuntime, ...) can be passed and are merged in. fromCronDecorator: false opts out. If no schedule can be derived, a debug warning says the settings were not sent.
  • A config with a schedule is used as is. The types reject mixing schedule/timezone with fromCronDecorator.
  • Without @Cron's timeZone, the job runs in the server's local zone, so that zone is sent.
  • 5-field expressions are sent as is, 6-field ones drop a fixed seconds field. Presets Sentry accepts are sent as is; @midnight, @minutely, @weekdays and @weekends are sent as crontabs. Sub-minute schedules, Dates, utcOffset, numeric months (cron 2.x counts them from 0), a */n day field combined with the other day field, and time zones Sentry doesn't accept send no config.
  • Monitors that already exist get their schedule and time zone from @Cron on each check-in; other settings are kept.

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>
wedamija and others added 4 commits October 2, 2026 12:57
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>
@wedamija
wedamija marked this pull request as ready for review October 2, 2026 22:28
@wedamija
wedamija requested a review from a team as a code owner October 2, 2026 22:28
@wedamija
wedamija requested review from chargome and nicohrubec and removed request for a team October 2, 2026 22:28

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant