How to monitor an API endpoint and get its response time

What to check

• The status code: a healthy endpoint answers 200, or whatever your API returns on success.
• The response time: an endpoint that answers in four seconds is as good as down for many apps.
• The certificate: an expired SSL certificate breaks every client at once, so you want a warning well before the date.
• The content path: use a real route (for example /health or a cheap read), not just the home page.

Create the monitor

1. Add a title and the address: use a name you will recognise in a list, and paste the full address of the endpoint.
2. Choose the method: GET for a read, or POST, PUT and others when the endpoint needs them. Add the headers it expects, such as an authorisation token or a content type, and a body if it needs one. Headers and body are stored encrypted.
3. Set the expected status: if your endpoint answers 201 or 204 instead of 200, say so, so a correct answer is not counted as a failure.
4. Set the timeout and redirects: pick how long to wait before the check counts as failed, and whether redirects should be followed.
5. Save it and run a quick request: you get the status, the response time and the size of the answer within seconds.

Read a detailed check

A quick request tells you whether the endpoint answered. A detailed request tells you why it was slow. It splits the time into DNS lookup, connection, TLS handshake and first byte, lists the redirects it followed, shows the response headers and reports when the SSL certificate expires.

If the DNS step is slow the problem is your name servers; if the connection or TLS step is slow it is the network or the server's capacity; if only the first byte is slow, your application is thinking too long. That one view usually saves an hour of guessing.

Turn on regular checks

You can run checks by hand whenever you want, and switch on a daily check for any monitor. Higher plans add hourly checks, and the Business plan adds checks every minute, which is the right choice for an endpoint your customers depend on all day.

Every check is saved. The page shows a chart of the response time and a table of results for the last 30 days, with failed checks marked in red, so you can see patterns such as a slow hour every night.

Tell your customers

Monitoring tells you first. To tell everyone else, link the monitor to a component of a status page: the page then shows the outage by itself and your support inbox stays quiet.

Questions about this guide

Can I monitor an endpoint that needs a token?

Yes. Add the token as a header. Headers and the request body are stored encrypted and are never shown in the list.

How long is the history kept?

Checks and response times are kept for 30 days, with a chart and a table. Per-minute checks are kept for 2 days.