Call the free ping api endpoint
curl https://aisenseapi.com/services/v1/ping{"ping":"pong"}Fifteen bytes, every time. There is no query string to build and no body to send, so nothing on the caller side can go wrong. The base URL is https://aisenseapi.com/services/v1 and it needs no key and no account. Copy the command above into any terminal and it runs as written.
Response field
| Field | Type | Description |
|---|---|---|
| ping | string | Always the literal pong. It is a constant rather than a computed value, so it never varies by time, caller or load. |
Read the HTTP status first and the body second. A 200 carrying {"ping":"pong"} proves that a request reached the service and that the service answered it. Anything else is an availability problem by elimination: a timeout, a DNS failure, a TLS error or a 502 from something sitting in front of the service. No application logic runs here that could invent an error of its own.
Cache headers you can trust
Ask curl for the response headers and the body disappears, leaving the part that matters for monitoring:
curl -s -D - -o /dev/null https://aisenseapi.com/services/v1/pingHTTP/2 200
server: AISENSE
cache-control: no-store, no-cache, must-revalidate, max-age=0
expires: Thu, 01 Jan 1970 00:00:00 GMT
pragma: no-cache
referrer-policy: no-referrer-when-downgrade
access-control-allow-origin: *
content-type: application/json
content-length: 15Those cache directives do real work. A cached success is worse than no answer at all, because a proxy would keep reporting a healthy service long after the process behind it died. The four values in cache-control close that door with older caches as well as new ones, and expires in 1970 repeats the message for anything that ignores the modern header.
Notice access-control-allow-origin: * too. Browser JavaScript can call this endpoint directly, which makes it usable as a connectivity probe inside a web app rather than only from a server.
Ping answers a different question than health
These two endpoints look similar and answer opposite halves of the same problem. Getting them mixed up is the classic monitoring mistake.
- Ping answers: is anything listening
It proves the DNS record resolves, the TLS handshake completes, the routing works and a process is returning HTTP. It proves nothing beyond that, and the free ping api endpoint makes no promise that it does.
- Health answers: are the parts working
The health check API endpoint reports the service's actual state. Reach for it when you need to know whether the service can do its job, not merely whether it exists.
- Choose by what you will do with the answer
Reachability tests, latency measurement and CI smoke tests want ping, because a fixed response keeps the measurement clean. Deciding whether to send real traffic wants health. A load balancer pointed at ping will happily keep routing to a process that is up but broken.
Measure round trip time with curl
The server does no work, so elapsed time here is close to pure network cost plus TLS. That makes ping a fair yardstick when you compare one location against another. Ask curl for the timing with -w and throw the body away:
curl -s -o /dev/null -w "%{http_code} in %{time_total}s\n" \
https://aisenseapi.com/services/v1/ping200 in 0.179022sThe first call to a host includes DNS resolution and a full TLS handshake, so it is always the slowest of the run. Repeat it three or four times and read the later numbers when you want steady state latency instead of cold start cost.
Common uses
Latency from a location
Time the round trip from a region, an office or a CI runner. A constant response size keeps the comparison honest.
CI connectivity gate
Run one ping before an integration suite. A failure means the runner has no outbound internet, and the suite would only produce confusing errors.
NAT keepalive
A client behind NAT or a corporate firewall can poll slowly to keep its outbound path from being reaped by an idle timeout.
First thing to try when something breaks
When another call misbehaves, one ping separates a broken network from a broken endpoint.
Agent internet check
An autonomous agent can confirm it really has outbound access before it reports a remote resource as unavailable.
Limits and polling rates
The free ping api endpoint counts against the service wide limit of 5000 requests per IP per 24 hours, exactly like every other endpoint. Being cheap to serve does not make it free of quota.
That budget is the one real way to get this call wrong. A monitor polling once per second would issue 86400 requests in a day and exhaust the allowance in under an hour, dragging the rest of your integration down with it. One request per 17 seconds is the sustained ceiling. Poll every 30 or 60 seconds instead: 1440 requests a day still catches an outage quickly and leaves most of the quota for real work.
The limit is counted per IP, so everything behind one office NAT or one CI egress address shares a single bucket. Unsure which address that is? The client IP API endpoint tells you the outbound address the quota is being charged to, and the IP reverse lookup API endpoint resolves that address back to its network.