Sentry Elixir Sdk

# Crons — Sentry Elixir SDK

> Minimum SDK: `sentry` v10.2.0+

Sentry Cron Monitoring detects when scheduled jobs fail silently — they don't error, but they stop running or take too long. The SDK provides three integration paths: manual check-ins (any scheduler), Oban (job queue), and Quantum (cron scheduler).

## Manual Check-Ins

Use `Sentry.capture_check_in/1` with any periodic task — `GenServer`, `Task`, or custom scheduler.

### Basic pattern: start → work → complete/error

```elixir
defmodule MyApp.ReportWorker do
  use GenServer

  def handle_info(:run, state) do
    # 1. Signal job started
    {:ok, check_in_id} = Sentry.capture_check_in(
      status: :in_progress,
      monitor_slug: "daily-report"
    )

    # 2. Do the work
    result = MyApp.Reports.generate_daily_report()

    # 3. Signal completion or failure
    case result do
      {:ok, _report} ->
        Sentry.capture_check_in(
          check_in_id: check_in_id,
          status: :ok,
          monitor_slug: "daily-report"
        )

      {:error, reason} ->
        Sentry.capture_check_in(
          check_in_id: check_in_id,
          status: :error,
          monitor_slug: "daily-report"
        )
        Logger.error("Report generation failed: #{inspect(reason)}")
    end

    {:noreply, state}
  end
end
```

### With monitor configuration (upsert)

Providing `monitor_config` creates or updates the monitor definition in Sentry on first check-in. This eliminates the need to create monitors in the Sentry UI manually:

```elixir
Sentry.capture_check_in(
  status: :in_progress,
  monitor_slug: "hourly-sync",
  monitor_config: [
    schedule: [type: :crontab, value: "0 * * * *"],   # runs every hour at :00
    timezone: "America/New_York",
    checkin_margin: 5,         # minutes before Sentry considers the check-in missed
    max_runtime: 30,           # minutes before Sentry considers the job failed
    failure_issue_threshold: 2,
    recovery_threshold: 2,
    owner: "platform-team"     # since v10.10.0
  ]
)
```

### Interval schedule

For jobs that run every N minutes/hours rather than on a crontab:

```elixir
Sentry.capture_check_in(
  status: :in_progress,
  monitor_slug: "health-probe",
  monitor_config: [
    schedule: [type: :interval, value: 15, unit: :minute],
    # unit options: :year | :month | :week | :day | :hour | :minute
    checkin_margin: 3,
    max_runtime: 5
  ]
)
```

### `capture_check_in/1` options

| Option | Type | Required | Description |
|--------|------|----------|-------------|
| `:status` | `:in_progress \| :ok \| :error` | Yes | Current job status |
| `:monitor_slug` | `string` | Yes | Unique identifier for the monitor (slug format) |
| `:check_in_id` | `string` | On completion | ID from the initial `:in_progress` call |
| `:duration` | `number` | No | Job duration in seconds (auto-calculated when using check_in_id) |
| `:monitor_config` | `keyword` | No | Monitor definition; upserted on each call |
| `:environment` | `string` | No | Override default environment for this check-in |

`capture_check_in/1` returns:
- `{:ok, check_in_id}` — check-in ID string; pass it to subsequent calls
- `:ignored` — not sent (no DSN, wrong environment, etc.)
- `{:error, ClientError.t()}` — HTTP error

### Helper wrapper pattern

For clean code, wrap the check-in lifecycle in a helper:

```elixir
defmodule MyApp.Crons do
  @doc """
  Runs a function as a Sentry-monitored cron job.
  Returns {:ok, result} or {:error, exception}.
  """
  def monitor(slug, fun, monitor_config \\ []) do
    {:ok, check_in_id} = Sentry.capture_check_in(
      status: :in_progress,
      monitor_slug: slug,
      monitor_config: monitor_config
    )

    try do
      result = fun.()

      Sentry.capture_check_in(
        check_in_id: check_in_id,
        status: :ok,
        monitor_slug: slug
      )

      {:ok, result}
    rescue
      exception ->
        Sentry.capture_check_in(
          check_in_id: check_in_id,
          status: :error,
          monitor_s