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:
{
"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.
{
"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
.
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").