Cron Monitoring Now Supports Sentry SDKs, Automatic Set Up, Multi-Environments and More
Last year we introduced Sentry Cron Monitoring (beta) to help developers get code-level context and performance trends for their scheduled jobs. While Crons remains in beta, we’ve heard your feedback over the past few months and want to share some big improvements we’ve shipped. In this post, we’ll cover how we’ve simplified the setup process by integrating Crons into our SDKs and automating monitor setup for select frameworks. Plus, how new features like timezone support, multiple environments, improved alerting, and attachments can help reduce downtime for your recurring jobs.
As you typically configure Sentry features through our SDKs, integrating Cron Monitoring into our SDKs was an obvious next step. Enabling the SDK setup for Crons was not only important for building a consistent experience across our products, but also simplified the setup process --- a lot. Now you can install Crons from the following SDKs: Python, Celery, PHP, Laravel, and Node.js.
If you previously set up a monitor, that process is going to look a lot different. In addition to simplifying the in-app quick start guide UX, when you create a monitor, Sentry will create a code snippet to copy-paste into your Sentry SDK or CLI.
Want to avoid configuration in Sentry altogether? Good news. You can automatically register monitors, eliminating the need for manual instrumentation of your app’s code. We currently support schedulers like Celerybeat or hosting Next.js in Vercel.
Here’s an example of how to enable Celerybeat auto instrumentation
# tasks.py from celery import signals import sentry_sdk from sentry_sdk.integrations.celery import CeleryIntegration #@signals.beat_init.connect @signals.celeryd_init.connect def init_sentry(**kwargs): sentry_sdk.init( dsn='https://examplePublicKey@o0.ingest.sentry.io/0', integrations=[CeleryIntegration(monitor_beat_tasks=True)], # 👈 environment="local.dev.grace", release="v1.0", )
Additionally, you can now specify monitor configuration via the API to quickly and easily create or update monitors through a check-in. This is especially helpful if you have multiple monitors or environments to configure.
When v0 of Cron Monitoring launched, some of the most common feature requests were the ability to define environments, time zones, and attachments for monitors. As these features are table stakes for monitoring a scheduled job, we went to work.
If you are using Sentry for error monitoring, you likely care more about errors in prod than in your dev environment. Specifying your monitor’s environment and the timezone it is running in gives you some much needed context for prioritizing missed or failed check-ins. Now you can define your monitor’s environment, filter for it via My Projects, and set the local timezone that the monitor runs in.
Now, just like event attachments for issues, you can send a file attachment via our API for your scheduled jobs. For example, if your job fails, you could include data like a log output or metrics like the number of items processed during job execution.
We’ve streamlined the process of setting up alerts right from the onboarding stage. You can now quickly configure monitor failure notifications in your preferred platform (Slack, Teams, or email) during the setup process.
Cron jobs are the unsung heroes of every application. They keep our servers humming, backups running, and perform countless other functions behind the scenes.
There’s more work to be done before we GA Cron Monitoring. For example, just like how you can connect performance slowdowns to error issues through distributed tracing, connecting failed check-ins to errors is priority number one. We also have committed to bringing Crons support for our Ruby, Java, .NET, and Go SDKs as well. Want to know what else we have planned? View the roadmap here and share your feedback on the GitHub Discussion thread.