Overview
The Create TCP Check endpoint allows you to create new TCP port monitoring checks to verify network connectivity, port availability, and service responsiveness at the network level. Common Use Cases:- Port Availability Monitoring
- Network Service Health Checks
- Database Connection Monitoring
- Service Discovery Verification
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
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.
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 <= 5000
The response time in milliseconds where a check should be considered failing.
0 <= x <= 5000
An array of one or more private locations where to run the check.
["data-center-eu"]
Response
Created
The name of the check.
"Check"
"9d6df684-0bc3-4a38-a094-4e97627dd93e"
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"]
TCP