# Set Up Crons | Sentry for ASP.NET

Once implemented, it'll allow you to get alerts and metrics to help you solve errors, detect timeouts, and prevent disruptions to your service.

If you are using [Hangfire](https://www.hangfire.io/.md), please see [how to setup monitoring for Hangfire jobs](https://docs.sentry.io/platforms/dotnet/guides/aspnet/crons/hangfire.md).

## [Requirements](https://docs.sentry.io/.md#requirements)

* Use our [getting started](https://docs.sentry.io/platforms/dotnet/guides/aspnet.md) guide to install and configure the Sentry .NET SDK (min 4.2.0) for your recurring job.
* [Create and configure](https://sentry.io/crons/create.md) your first Monitor.

## [Check-Ins (Recommended)](https://docs.sentry.io/.md#check-ins-recommended)

Check-in monitoring allows you to track a job's progress by completing two check-ins: one at the start of your job and another at the end of your job. This two-step process allows Sentry to notify you if your job didn't start when expected (missed) or if it exceeded its maximum runtime (failed).

```csharp
// 🟡 Notify Sentry your job is running:
var checkInId = SentrySdk.CaptureCheckIn("<monitor-slug>", CheckInStatus.InProgress);

// Execute your scheduled task here...

// 🟢 Notify Sentry your job has completed successfully:
SentrySdk.CaptureCheckIn("<monitor-slug>", CheckInStatus.Ok, checkInId);
```

If your job execution fails, you can notify Sentry about the failure:

```csharp
// 🔴 Notify Sentry your job has failed:
SentrySdk.CaptureCheckIn("<monitor-slug>", CheckInStatus.Error, checkInId);
```

## [Alerts](https://docs.sentry.io/.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`

[![Cron completed alert filter](https://docs.sentry.io/_next/image/?url=%2Fmdx-images%2Fcrons-alerts-example-CJJAWX24.png%231956x1084\&w=3840\&q=75)](https://docs.sentry.io/mdx-images/crons-alerts-example-CJJAWX24.png)

Learn more in [Issue Alert Configuration](https://docs.sentry.io/product/alerts/create-alerts/issue-alert-config.md).

## [Rate Limits](https://docs.sentry.io/.md#rate-limits)

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](https://docs.sentry.io/product/stats.md#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.
