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 thestatus is
okorerror. release- String, optional. The release.
environment- String, optional. The environment.
monitor_config- Object, optional. A monitor configuration (defined below) that is stored with thecheck-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 runningthe check-in. Right now we only support the trace contextand use the
trace_idin 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 expectedcheck-in time that the monitor will not be considered missed for.
max_runtime- Number, optional. The allowed duration in minutes that the monitormay be
in_progressfor before being considered failed due to timeout. failure_issue_threshold- Number, optional. The number of consecutive failed check-ins it takesbefore an issue is created.
recovery_threshold- Number, optional. The number of consecutive OK check-ins it takesbefore an issue is resolved.
timezone- String, optional. A
tz databasestringrepresenting the timezone which the monitor's execution schedule is in. owner- String, optional. An actor identifier string. This looks like
user:john@example.comteam:a-sentry-team. IDs can also be used but willresult in a poor DX.
This configuration format differs slightly from what is accepted in the monitors frontend APIs.
type- String, required. One of
crontaborinterval.
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").
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").