Check-Ins

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

Copied
{
  "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.

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.

Copied
{
  "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.

This configuration format differs slightly from what is accepted in the monitors frontend APIs.

type
String, required. One of crontab or interval.

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

value
Number, required. The interval value.
unit
String, required. The interval unit. Should be one of year, month, week, day, hour, minute.
Help improve this content
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").