Crons: Handle implementation-specific day-of-month and day-of-week interactions correctly in crontab schedules

[szokeasaurusrex]

While the crontab syntax is standardized, the way of handling interactions between the day-of-month and day-of-week fields varies between commonly used implementations.

Take for example the schedule 0 0 1 * 1. The first 1 indicates that this schedule should run on the first day of the month, and the second 1 indicates that the schedule should run on Monday. The way Sentry would interpret this schedule, which is also the way most UNIX systems would interpret this schedule, is that the task should run the first day of every month, and also every Monday (a union of the day-of-month and day-of-week fields). However, other systems, such as Celery, only run when all of the fields are matched (an intersection), so Celery would run this schedule only on the first day of the month, and only if that day is a Monday (way less often than Sentry would expect).

Sentry itself also appears to handle certain schedules inconsistently. Take for instance this example Cron monitor with a schedule of 0 0 */15 * 1. The day of month */15 indicates that the schedule should run every 15th day of in a month, and the 1 indicates the schedule should run every Monday. The human-readable schedule written on the page indicates that the job should run "At 00:00, every 15 days, and on Monday (UTC)"; however, if we check the next expected execution, which is three weeks from today (May 23), we see that the next expected execution is actually the next 15th day of the month, which is also a Monday (June 16).

Screen.Recording.2025-05-23.at.14.25.58.mov

We need to fix these inconsistencies within the UI itself, and also enable Sentry to support correctly ingesting crontab schedules from different systems, which may have different ways of handling inconsistencies between the day-of-week and day-of-month fields. My recommendation would be the following:

1. Resolve the UI inconsistencies by clearly specifying how Sentry interprets crontab values (I was unable to find any such specification in our develop docs), then aligning the logic to that specification.
2. Expose a mechanism to override how the conflict between day-of-month and day-of-week should be resolved, in order to support monitoring crons from systems which may resolve this conflict differently from how Sentry typically does (systems like Celery need this in order to be supported correctly). SDKs would then use this mechanism to specify in any monitor upsets how the crontab schedule should be interpreted

[getsantry]

Routing to @getsentry/product-owners-crons for triage ⏲️