Free Health Check API Endpoint

Call the free health check API endpoint

curl https://aisenseapi.com/services/v1/health

{"status":"ok","microtimestamp":1787172036.878165}

HTTP 200 with a JSON body. There are no headers to set, no query string and no request body. A monitoring tool that accepts nothing but a URL can use the endpoint exactly as it stands.

Assert on the status field, not on the HTTP code alone. A proxy or a load balancer in front of the service can keep returning 200 long after the service behind it has stopped doing useful work.

Response fields

Field	Type	Description
status	string	`ok` when the service considers itself able to serve requests. Anything else, including no response at all or a body that fails to parse, should be treated as not operational.
microtimestamp	number	Unix time in seconds with a microsecond fraction, read from the server's clock as the response was built.

Why the timestamp earns its place

A status field on its own tells you what some machine believed at some unnamed moment. The timestamp turns that belief into a claim you can check.

It proves the reply is fresh
A cached copy carries the timestamp of the moment it was first built, not the moment you asked. Poll twice a few seconds apart and compare the two numbers. If the value barely moves, something between you and the service is answering on its behalf, and the green check means nothing at all.
It exposes clock skew
Subtract the value from your own clock as the response lands. What remains is round trip time plus the drift between the two machines. Round trip is tens of milliseconds. Anything much larger is drift, and drift is the kind of fault that hides quietly until it breaks something.
It costs nothing to collect
You are already polling for status. Recording the delta beside it turns an up or down check into a running measurement of how far apart your systems believe the time to be.

Read both clocks in one line and compare them:

curl -s https://aisenseapi.com/services/v1/health; date +%s.%N

{"status":"ok","microtimestamp":1787179488.909188}
1787179414.962940500

That machine sits about 73.9 seconds behind the service. It sounds harmless. Then a time window check refuses a token that has not expired yet, or accepts one that has, and the logs on both sides look perfectly reasonable because each machine agrees with itself.

Exactly that drift, a little over a minute, caused real trouble in this project before anyone thought to compare the two clocks. A poll of the free health check API endpoint that also records the delta would have named the fault on the very first check.

Health versus ping

The two probes answer different questions. The Ping API Endpoint replies with a fixed pong. That proves a process accepted the connection and wrote a reply, which is all you want from the cheapest possible reachability probe. It says nothing about whether that process can do any work.

Poll health when the real question is whether the service is fit to serve requests rather than merely listening on a socket. Reach for ping when you are testing a network path or warming a connection. Reach for health when a monitor, a status page or a deployment is about to make a decision from the answer.

When a check fails and you need to know which address the service actually saw, the Client IP API Endpoint reports the caller address as it arrives.

Common uses

Uptime monitor URL

Point the check at the endpoint and assert on status being ok, not just on HTTP 200.

Status page source

Drive a public component indicator from a single field instead of scraping a page.

Readiness gate

Hold a deployment at the traffic cutover until the new target answers with a healthy status.

Drift detection

Log the gap between the server clock and yours on every poll and alert when it grows past a second.

Agent preflight

Let a language model confirm the service is up before it starts a long batch of calls.

Polling interval and limits

The service-wide limit is 5000 requests per IP per 24 hours, and health polls count against it exactly like any other call.

Pick an interval that stays well inside that budget. A check every minute uses 1440 requests a day and leaves plenty of room for real work from the same address. Every 30 seconds uses 2880, which fits but crowds nearly everything else out. Every 10 seconds is 8640 and will start returning rate limit errors before the day is over, turning the monitor itself into the source of the alarm.

Share the allowance carefully when the free health check API endpoint is polled from the address that also serves your production traffic. One address, one budget. Every service in the free public REST APIs catalogue draws from the same 5000 calls, so a monitor set too eager will quietly starve the work it was meant to protect.