Overview
The Update API Check endpoint allows you to modify existing API monitoring checks, including request parameters, response assertions, scheduling, and monitoring locations. Common Use Cases:- API Check Maintenance
- Request Parameter Updates
- Assertion Modifications
- Schedule Changes
Authorizations
The Checkly Public API uses API keys to authenticate requests. You can get the API Key here.
Your API key is like a password: keep it secure!
Authentication to the API is performed using the Bearer auth method in the Authorization header and using the account ID.
For example, set Authorization header while using cURL:
curl -H "Authorization: Bearer [apiKey]" "X-Checkly-Account: [accountId]"
Headers
Your Checkly account ID, you can find it at https://app.checklyhq.com/settings/account/general
Path Parameters
Query Parameters
Determines whether a new check will automatically be added as a subscriber to all existing alert channels when it gets created.
Body
The name of the check.
"Check"
Determines if the check is running or not.
Determines if any notifications will be send out when a check fails and/or recovers.
[Deprecated] Retry failed check runs. This property is deprecated, and retryStrategy
can be used instead.
Allows to invert the behaviour of when a check is considered to fail. Allows for validating error status like 404.
An array of one or more data center locations where to run this check.
["us-east-1", "eu-central-1"]
Tags for organizing and filtering checks.
["production"]
Alert settings.
When true, the account level alert setting will be used, not the alert setting defined on this check.
The id of the check group this check is part of.
null
The position of this check in a check group. It determines in what order checks are run when a group is triggered from the API or from CI/CD.
x >= 0
null
The runtime version, i.e. fixed set of runtime dependencies, used to execute this check.
2025.04
, 2024.09
, 2024.02
, 2023.09
, 2023.02
, 2022.10
List of alert channel subscriptions.
[]
The strategy to determine how failed checks are retried.
When true, the check will run in parallel in all selected locations.
Determines the request that the check is going to run.
How often the check should run in minutes.
0
, 1
, 2
, 5
, 10
, 15
, 30
, 60
, 120
, 180
, 360
, 720
, 1440
Used for setting seconds for check frequencies under 1 minutes (only for API & TCP checks) and spreading checks over a time range for frequencies over 1 minute. This works as follows: Checks with a frequency of 0 can have a frequencyOffset of 10, 20 or 30 meaning they will run every 10, 20 or 30 seconds. Checks with a frequency lower than and equal to 60 can have a frequencyOffset between 1 and a max value based on the formula "Math.floor(frequency * 10)", i.e. for a check that runs every 5 minutes the max frequencyOffset is 50. Checks with a frequency higher than 60 can have a frequencyOffset between 1 and a max value based on the formula "Math.ceil(frequency / 60)", i.e. for a check that runs every 720 minutes, the max frequencyOffset is 12.
x >= 1
The response time in milliseconds where a check should be considered degraded.
0 <= x <= 30000
The response time in milliseconds where a check should be considered failing.
0 <= x <= 30000
An array of one or more private locations where to run the check.
["data-center-eu"]
An ID reference to a snippet to use in the teardown phase of an API check.
null
An ID reference to a snippet to use in the setup phase of an API check.
null
A valid piece of Node.js code to run in the setup phase.
""
A valid piece of Node.js code to run in the teardown phase.
""
Response
Successful
The name of the check.
"Check"
"2739d22d-086f-481d-a484-8b93ac84de61"
Determines if the check is running or not.
Determines if any notifications will be send out when a check fails and/or recovers.
[Deprecated] Retry failed check runs. This property is deprecated, and retryStrategy
can be used instead.
Allows to invert the behaviour of when a check is considered to fail. Allows for validating error status like 404.
An array of one or more data center locations where to run this check.
["us-east-1", "eu-central-1"]
Tags for organizing and filtering checks.
["production"]
Alert settings.
When true, the account level alert setting will be used, not the alert setting defined on this check.
The id of the check group this check is part of.
null
The position of this check in a check group. It determines in what order checks are run when a group is triggered from the API or from CI/CD.
x >= 0
null
The runtime version, i.e. fixed set of runtime dependencies, used to execute this check.
2025.04
, 2024.09
, 2024.02
, 2023.09
, 2023.02
, 2022.10
The strategy to determine how failed checks are retried.
When true, the check will run in parallel in all selected locations.
How often the check should run in minutes.
0
, 1
, 2
, 5
, 10
, 15
, 30
, 60
, 120
, 180
, 360
, 720
, 1440
Used for setting seconds for check frequencies under 1 minutes (only for API & TCP checks) and spreading checks over a time range for frequencies over 1 minute. This works as follows: Checks with a frequency of 0 can have a frequencyOffset of 10, 20 or 30 meaning they will run every 10, 20 or 30 seconds. Checks with a frequency lower than and equal to 60 can have a frequencyOffset between 1 and a max value based on the formula "Math.floor(frequency * 10)", i.e. for a check that runs every 5 minutes the max frequencyOffset is 50. Checks with a frequency higher than 60 can have a frequencyOffset between 1 and a max value based on the formula "Math.ceil(frequency / 60)", i.e. for a check that runs every 720 minutes, the max frequencyOffset is 12.
x >= 1
An array of one or more private locations where to run the check.
["data-center-eu"]
Determines the request that the check is going to run.
API
An ID reference to a snippet to use in the teardown phase of an API check.
An ID reference to a snippet to use in the setup phase of an API check.
A valid piece of Node.js code to run in the setup phase.
""
A valid piece of Node.js code to run in the teardown phase.
""