Check-Ins

Cron Monitor Check-In Payload

A check-in is an item in an envelope called check_in. It consists of a JSON payload that looks roughly like this:

{
  "check_in_id": "83a7c03ed0a04e1b97e2e3b18d38f244",
  "monitor_slug": "my-monitor",
  "status": "in_progress",
  "duration": 10.0,
  "release": "1.0.0",
  "environment": "production",
  "contexts": {
    "trace": {
      "trace_id": "8f431b7aa08441bbbd5a0100fd91f9fe"
    }
  }
}

The following fields exist:

check_in_id

String, required. Check-In ID (unique and client generated).

This may be provided as a empty UUID (128 bit zero value) to indicate to Sentry that the checkin should update the most recent "in_progress" check-in. If the most recent check-in is not in progress a new one will be created instead.

monitor_slug

String, required. The distinct slug of the monitor.

status

String, required. The status of the check-in. Can be one of the following:

• in_progress: The check-in has started.
• ok: The check-in has completed successfully.
• error: The check-in has failed.

duration

Number, optional. The duration of the check-in in seconds. Will only take effect if the

status is ok or error.

release

String, optional. The release.

environment

String, optional. The environment.

monitor_config

Object, optional. A monitor configuration (defined below) that is stored with the

check-in in order to verify the state of the monitor at the time of the check-in.

contexts

Object, optional. A dictionary of contextual information about the environment running

the check-in. Right now we only support the trace context

and use the trace_id in order to link check-ins to associated errors.

Monitor upsert support

In addition to sending check-in details, the SDK may also provide monitor configuration, allowing monitors to be created or updated when sending check-ins.

{
  "check_in_id": "83a7c03ed0a04e1b97e2e3b18d38f244",
  "monitor_slug": "b7645b8e-b47d-4398-be9a-d16b0dac31cb",
  "status": "in_progress",
  "monitor_config": {
    "schedule": {
      "type": "crontab",
      "value": "0 * * * *"
    },
    "checkin_margin": 5,
    "max_runtime": 30,
    "failure_issue_threshold": 2,
    "recovery_threshold": 2,
    "timezone": "America/Los_Angeles",
    "owner": "user:john@example.com"
  }
}

The following fields exist under the monitor_config key:

schedule

Object, required. See schedule configuration.

checkin_margin

Number, optional. The allowed margin of minutes after the expected

check-in time that the monitor will not be considered missed for.

max_runtime

Number, optional. The allowed duration in minutes that the monitor

may be in_progress for before being considered failed due to timeout.

failure_issue_threshold

Number, optional. The number of consecutive failed check-ins it takes

before an issue is created.

recovery_threshold

Number, optional. The number of consecutive OK check-ins it takes

before an issue is resolved.

timezone

String, optional. A tz database string

representing the timezone which the monitor's execution schedule is in.

owner

String, optional. An actor identifier string. This looks like

user:john@example.com team:a-sentry-team. IDs can also be used but will

result in a poor DX.

Schedule configuration

type

String, required. One of crontab or interval.

Using crontab

value

String, required. The crontab schedule string, e.g. 0 * * * *.

Using interval

value

Number, required. The interval value.

unit

String, required. The interval unit. Should be one of year, month, week, day, hour, minute.

Interaction with beforeSend

Check-in events in the SDK should not go through beforeSend. SDKs can optionally implement a dedicated beforeSendCheckIn hook that only applies to check-in events.