Celery Beat auto-instrumentation: allow configuring monitor limits (max_runtime, checkin_margin, ...) #7838

Problem

When CeleryIntegration(monitor_beat_tasks=True) is used, the SDK auto-creates a Cron Monitor per Celery Beat task. The monitor config it sends is derived from the schedule only:

• schedule
• timezone

(see _get_monitor_config in sentry_sdk/integrations/celery/beat.py).

There is currently no way to set max_runtime, checkin_margin, failure_issue_threshold, recovery_threshold, or owner on those auto-created monitors. CeleryIntegration only accepts propagate_traces, monitor_beat_tasks, and exclude_beat_tasks.

Impact

Sentry's default max_runtime is 30 minutes. Any beat task that legitimately runs longer than that is reported as a timed-out cron failure even when it completes successfully. The same applies to checkin_margin (clock drift / early or late check-ins) and to the issue thresholds.

The only workarounds today are:

• exclude the task via exclude_beat_tasks and instrument it manually with @sentry_sdk.monitor(..., monitor_config=...). This forces you to duplicate the schedule in code, which is a problem if it differs per environment, or
• post-process the check-in event with before_send.

Proposal

Add a beat_task_monitor_config option to CeleryIntegration: a mapping of Celery Beat task name to a partial MonitorConfig that is merged into the config derived from the schedule.

import sentry_sdk
from sentry_sdk.integrations.celery import CeleryIntegration

sentry_sdk.init(
    integrations=[
        CeleryIntegration(
            monitor_beat_tasks=True,
            beat_task_monitor_config={
                "nightly-cleanup": {"max_runtime": 120, "checkin_margin": 10},
            },
        ),
    ],
)

The SDK would still derive schedule and timezone; the override only needs the additional fields. Keys are the task names as they appear in the Celery Beat schedule (same names used by exclude_beat_tasks). Values would also be able to override the derived schedule/timezone if explicitly provided.

I have a working implementation with tests and can open a PR if this approach sounds reasonable.