Set Up Crons
Monitor your scheduled jobs with Sentry - choose the setup method that works best for you.
Monitor the uptime and performance of your scheduled jobs in Node.js. Get alerts when jobs fail, timeout, or don't run as expected.
Choose the method that matches your current setup:
- UI Setup - Create monitors in Sentry's web interface, then add instrumentation
- node-cron - Auto-instrument node-cron library
- cron - Auto-instrument cron library
- node-schedule - Auto-instrument node-schedule library
If you're using one of these popular cron libraries, use the automatic integration for seamless monitoring.
- Job Monitoring - Use withMonitor wrapper for automatic status tracking
- Check-Ins - Full control with manual status updates
- Heartbeat - Simple success/failure notifications
- Upserting Monitors - Programmatic monitor creation and management
These methods work but don't provide the full benefits of SDK integration like tracing and error context:
- Sentry CLI - Command-line tool for basic monitoring
- HTTP API - Direct API calls for check-ins
If you have custom cron logic or use a different scheduling library, we recommend Check-Ins which gives you full control over when and how status updates are sent.
For advanced use cases like CI/CD pipelines or managing many monitors, consider Upserting Monitors which lets you create monitors programmatically via code.
When your recurring job fails to check in (missed), runs beyond its configured maximum runtime (failed), or manually reports a failure, Sentry will create an error event with a tag to your monitor.
To receive alerts about these events:
- Navigate to Alerts in the sidebar.
- Create a new alert and select "Issues" under "Errors" as the alert type.
- Configure your alert and define a filter match to use:
The event's tags match {key} {match} {value}.
Example: The event's tags match monitor.slug equals my-monitor-slug-here
Learn more in Issue Alert Configuration.
Crons imposes a rate limit on check-ins to prevent abuse and resource overuse. Specifically, you can only send a maximum of 6 check-ins per minute per existing monitor environment. This limit is enforced on a per-project basis, meaning that the rate limit applies collectively to all monitor environments within a given project. You can check if any of your check-ins are being dropped in the Usage Stats page.
To avoid dropped check-ins, it is crucial to manage and distribute your check-ins efficiently within the rate limits. This will help maintain accurate monitoring and ensure that all critical check-ins are captured and processed.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").