# Set Up Crons | Sentry for Laravel
Once implemented, it'll allow you to get alerts and metrics to help you solve errors, detect timeouts, and prevent disruptions to your service.
## [Requirements](https://docs.sentry.io/platforms/php/guides/laravel/crons.md#requirements)
* Use our [getting started](https://docs.sentry.io/platforms/php/guides/laravel.md) guide to install and configure the Sentry Laravel SDK (min v3.3.1) for your recurring job.
## [Job Monitoring](https://docs.sentry.io/platforms/php/guides/laravel/crons.md#job-monitoring)
Use the Laravel SDK to monitor and notify you if your [scheduled task](https://laravel.com/docs/10.x/scheduling) is missed (or doesn't start when expected), if it fails due to a problem in the runtime (such as an error), or if it fails by exceeding its maximum runtime.
To set up, add the `sentryMonitor()` macro to the scheduled tasks defined in your application as shown below. (Please note, this will create a Cron monitor that will count against your quota.)
`routes/console.php`
```php
Schedule::command(SendEmailsCommand::class)
->everyHour()
->sentryMonitor(); // add this line
```
Tasks that use Laravel's `between`, `unlessBetween`, `when` and `skip` methods are currently not supported. For the best results, we recommend using Laravel's [`cron`](https://laravel.com/docs/10.x/scheduling#schedule-frequency-options) method to define your schedule's frequency.
## [Configure a Job Monitor](https://docs.sentry.io/platforms/php/guides/laravel/crons.md#configure-a-job-monitor)
By default, the Laravel SDK will infer various parameters of your scheduled task. For greater control, we expose some optional parameters on the `sentryMonitor()` macro.
`routes/console.php`
```php
Schedule::command(SendEmailsCommand::class)
->everyHour()
->sentryMonitor(
// Specify the slug of the job monitor in case of duplicate commands or if the monitor was created in the UI.
monitorSlug: null,
// Number of minutes before a check-in is considered missed.
checkInMargin: 5,
// Number of minutes before an in-progress check-in is marked timed out.
maxRuntime: 15,
// Create a new issue when this many consecutive missed or error check-ins are processed.
failureIssueThreshold: 1,
// Resolve the issue when this many consecutive healthy check-ins are processed.
recoveryThreshold: 1,
// In case you want to configure the job monitor exclusively in the UI, you can turn off sending the monitor config with the check-in.
// Passing a monitor-slug is required in this case.
updateMonitorConfig: false,
)
```
## [Alerts](https://docs.sentry.io/platforms/php/guides/laravel/crons.md#alerts)
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:
1. Navigate to **Alerts** in the sidebar.
2. Create a new alert and select "Issues" under "Errors" as the alert type.
3. 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](https://docs.sentry.io/product/alerts/create-alerts/issue-alert-config.md).
## [Rate Limits](https://docs.sentry.io/platforms/php/guides/laravel/crons.md#rate-limits)
To prevent abuse and resource overuse, Crons limits check-ins to **6 per minute for each monitor environment**.
For example, if you have a monitor called "database-backup" with two environments:
* `database-backup` in environment `production` can send up to 6 check-ins per minute
* `database-backup` in environment `staging` can also send up to 6 check-ins per minute
* Combined, they can send up to 12 check-ins per minute
You can verify if any check-ins are being dropped by visiting the [Usage Stats](https://docs.sentry.io/product/stats.md#usage-stats) page. To avoid dropped check-ins, ensure your monitors don't exceed the rate limit.