With the Pinging API, you can signal success, start, and failure events from your systems.
All ping endpoints support:
Successful responses will have the "200 OK" HTTP response status code and a short "OK" string in the response body.
Each Pinging API request needs to uniquely identify a check. Hostchecks supports two ways of identifying a check: by check's UUID, or by a combination of project's Ping Key and check's slug.
Check's UUID is automatically assigned when the check is created. It is immutable. You cannot replace the automatically assigned UUID with a manually chosen one. When you delete a check, you also lose its UUID and cannot get it back.
You can look up UUIDs of your checks in web UI or via Management API calls.
Check's slug is derived from the check's name using Django's slugify function. It applies the following transformations:
For example, if check's name is "Database Backup", its slug is database-backup.
Check's slug can change. Hostchecks updates check's slug whenever its name changes.
Check's slug is not guaranteed to be unique. If multiple checks in the project have the same name, they also have the same slug. If you make a Pinging API request using a non-unique slug, Hostchecks will return the "409 Conflict" HTTP status code and ignore the request.
| Endpoint Name | Endpoint Address |
|---|---|
| Success (UUID) | https://uptime.hostchecks.in/ping/<uuid> |
| Start (UUID) | https://uptime.hostchecks.in/ping/<uuid>/start |
| Failure (UUID) | https://uptime.hostchecks.in/ping/<uuid>/fail |
| Log (UUID) | https://uptime.hostchecks.in/ping/<uuid>/log |
| Report script's exit status (UUID) | https://uptime.hostchecks.in/ping/<uuid>/<exit-status> |
| Success (slug) | https://uptime.hostchecks.in/ping/<ping-key>/<slug> |
| Start (slug) | https://uptime.hostchecks.in/ping/<ping-key>/<slug>/start |
| Failure (slug) | https://uptime.hostchecks.in/ping/<ping-key>/<slug>/fail |
| Log (slug) | https://uptime.hostchecks.in/ping/<ping-key>/<slug>/log |
| Report script's exit status (slug) | https://uptime.hostchecks.in/ping/<ping-key>/<slug>/<exit-status> |
HEAD|GET|POST https://uptime.hostchecks.in/ping/<uuid>
Signals to Hostchecks that the job has completed successfully (or, a continuously running process is still running and healthy).
Hostchecks identifies the check by the UUID value included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. If run ID is specified, Hostchecks uses it to match the correct corresponding start ping for this ping, and calculate an accurate duration. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
GET /5bf66975-d4c7-4bf5-bcc8-b8d8a82ea278 HTTP/1.0
Host: hc-ping.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<uuid>/start
Sends a "job has started!" message to Hostchecks. Sending a "start" signal is optional, but it enables a few extra features:
Hostchecks identifies the check by the UUID value included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. If run ID is specified, Hostchecks uses it to match the correct corresponding completion ping for this ping, and calculate an accurate duration. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
GET /5bf66975-d4c7-4bf5-bcc8-b8d8a82ea278/start HTTP/1.0
Host: hc-ping.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<uuid>/fail
Signals to Hostchecks that the job has failed. Actively signaling a failure minimizes the delay from your monitored service failing to you receiving an alert.
Hostchecks identifies the check by the UUID value included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. If run ID is specified, Hostchecks uses it to match the correct corresponding start ping for this ping, and calculate an accurate duration. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
GET /5bf66975-d4c7-4bf5-bcc8-b8d8a82ea278/fail HTTP/1.0
Host: hc-ping.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<uuid>/log
Sends logging information to Hostchecks without signaling success or failure. Hostchecks will log the event and display it in check's "Events" section with the "Log" label. The check's status will not change.
Hostchecks identifies the check by the UUID value included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
POST /5bf66975-d4c7-4bf5-bcc8-b8d8a82ea278/log HTTP/1.1
Host: hc-ping.com
Content-Type: text/plain
Content-Length: 11
Hello World
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<uuid>/<exit-status>
Sends a success or failure signal depending on the exit status included in the URL. The exit status is a 0-255 integer. Hostchecks interprets 0 as a success and all other values as a failure.
Hostchecks identifies the check by the UUID value included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. If run ID is specified, Hostchecks uses it to match the correct corresponding start ping for this ping, and calculate an accurate duration. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
GET /5bf66975-d4c7-4bf5-bcc8-b8d8a82ea278/1 HTTP/1.0
Host: hc-ping.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<ping-key>/<slug>
Signals to Hostchecks that the job has completed successfully (or, a continuously running process is still running and healthy).
Hostchecks identifies the check by project's ping key and check's slug included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. If run ID is specified, Hostchecks uses it to match the correct corresponding start ping for this ping, and calculate an accurate duration. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
GET /fqOOd6-F4MMNuCEnzTU01w/database-backup HTTP/1.0
Host: hc-ping.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<ping-key>/<slug>/start
Sends a "job has started!" message to Hostchecks. Sending a "start" signal is optional, but it enables a few extra features:
Hostchecks identifies the check by project's ping key and check's slug included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. If run ID is specified, Hostchecks uses it to match the correct corresponding completion ping for this ping, and calculate an accurate duration. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
GET /fqOOd6-F4MMNuCEnzTU01w/database-backup/start HTTP/1.0
Host: hc-ping.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<ping-key/<slug>/fail
Signals to Hostchecks that the job has failed. Actively signaling a failure minimizes the delay from your monitored service failing to you receiving an alert.
Hostchecks identifies the check by project's ping key and check's slug included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. If run ID is specified, Hostchecks uses it to match the correct corresponding start ping for this ping, and calculate an accurate duration. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
GET /fqOOd6-F4MMNuCEnzTU01w/database-backup/fail HTTP/1.0
Host: hc-ping.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<ping-key/<slug>/log
Sends logging information to Hostchecks without signaling success or failure. Hostchecks will log the event and display it in check's "Events" section with the "Log" label. The check's status will not change.
Hostchecks identifies the check by project's ping key and check's slug included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
POST /fqOOd6-F4MMNuCEnzTU01w/database-backup/log HTTP/1.1
Host: hc-ping.com
Content-Type: text/plain
Content-Length: 11
Hello World
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK
HEAD|GET|POST https://uptime.hostchecks.in/ping/<ping-key>/<slug>/<exit-status>
Sends a success or failure signal depending on the exit status included in the URL. The exit status is a 0-255 integer. Hostchecks interprets 0 as a success and all other values as a failure.
Hostchecks identifies the check by project's ping key and check's slug included in the URL.
The response may optionally contain a Ping-Body-Limit: <n> response header.
If this header is present, its value is an integer, and it specifies how many
bytes from the request body Hostchecks will store per request. For example, if n=100,
but the client sends 123 bytes in the request body, Hostchecks will store the first
100 bytes, and ignore the remaining 23. The client can use this header to decide
how much data to send in the request bodies of subsequent requests.
Optional, specifies a run ID of this ping. If run ID is specified, Hostchecks uses it to match the correct corresponding start ping for this ping, and calculate an accurate duration. The value must be a client-picked UUID in the canonical textual representation.
Example: rid=123e4567-e89b-12d3-a456-426614174000.
Example
GET /fqOOd6-F4MMNuCEnzTU01w/database-backup/1 HTTP/1.0
Host: hc-ping.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2020 09:58:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: close
Access-Control-Allow-Origin: *
Ping-Body-Limit: 10000
OK