API uptime monitoring

API uptime monitoring sends a GET to one public route of your API on a fixed interval, records the status code and the response time, and alerts you the moment the answer falls outside 200-399 or does not arrive within 10 seconds.

Most API outages are not the process dying. The server keeps accepting connections while the database pool is exhausted, and every real request returns 500. A check pointed at the bare API host gets a 404 or a framework welcome page and reports green through the whole incident. So the first decision is not which tool, it is which route. Point the check at a route that fails for the same reasons a real request fails.

What an API uptime checker asserts

Here is exactly what a Logdash check does, read from the monitor code rather than the marketing page. One GET request, one 10-second deadline for the whole exchange, up to 5 redirects followed. Then a verdict on the status line.

Status code: 200 to 399 is up. Any 4xx or 5xx is down.
Nothing answered: a refused connection, a reset, a hostname that does not resolve, or no reply within 10 seconds is down, recorded as status 0 with the reason.
Response time: recorded on every check and charted. There is no threshold alert on it yet, so an API that answers in 9 seconds stays green.
Body, JSON fields and response headers: not asserted. Only the status line decides up or down.

The alert fires on the transition. The first failed check flips the monitor to down and sends the status code plus the first 1,000 characters of the response body, so the error message your API returned lands in the alert. The next good check sends the recovery.

No custom headers, no auth

A monitor sends a plain GET with no custom headers, no bearer token and no body. The URL also has to resolve to a public address, so localhost and private IP ranges are refused. That means the monitored route has to be public. For a health route that is the right design anyway: one boolean in the body, no versions, no hostnames, nothing worth stealing. If the API only lives on a private network, push monitors on Pro flip the direction: something inside calls POST https://api.logdash.io/ping/<monitorId> at least once every 15 seconds, and silence is the failure.

The route to point it at

server.js

import express from 'express';
import pg from 'pg';

const app = express();
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });

// Registered before the auth middleware. A monitor sends no headers,
// so behind auth this route would answer 401 and read as down.
app.get('/health', async (req, res) => {
  res.set('Cache-Control', 'no-store');
  try {
    await pool.query('select 1');
    res.status(200).json({ ok: true });
  } catch {
    // 503 is what flips the monitor to down.
    res.status(503).json({ ok: false });
  }
});

// Everything registered after this line needs a key.
app.use((req, res, next) => {
  if (req.get('authorization') !== `Bearer ${process.env.API_KEY}`) {
    return res.status(401).json({ error: 'unauthorized' });
  }
  next();
});

app.get('/v1/orders', (req, res) => res.json([]));

app.listen(process.env.PORT ?? 3000);

API status monitoring in three steps

Add the health URL Create a service in Logdash and paste https://api.yourapp.com/health. The first check runs straight away, so a wrong path shows up in seconds, not during an incident.
Pick the interval Every 5 minutes on the free plan, every minute on Builder at $9 a month, every 15 seconds on Pro at $15 a month. At 15 seconds that is 5,760 requests a day against the route, which is why it runs select 1 and nothing heavier.
Break it on purpose Stop the database and leave the API running. The route starts returning 503, the next check flips the monitor to down, and a Telegram alert arrives with the monitor name, the status code and the error body.

Logdash vs Checkly

Feature	Logdash	Checkly
What a check can assert	Status code 200-399 within 10 seconds	Status code, headers, JSON body, text body and response time
Request options	GET only, no headers, no auth	Any common method, custom headers, request body, basic auth, setup scripts
Free plan volume	5 services every 5 minutes, about 43,000 checks a month	10,000 API check runs a month
Free alert channels	Telegram, plus a GET-only webhook with no payload	Email, Slack and webhook
Cheapest paid plan	$9 a month, 1-minute checks	$24 a month

When Checkly is the better pick

You need to assert on the JSON body, a header or a field value, not just the status line.
The endpoint you care about needs a token, a POST body or a login step before it answers.
You want the checks written in TypeScript in the same repository as the API and deployed from CI.

What is API uptime monitoring?

A service outside your infrastructure calls one route of your API on a schedule and alerts you when it stops answering or answers with an error. Logdash does it every 5 minutes free, every minute on Builder and every 15 seconds on Pro.

What is API status monitoring?

The same check, plus somewhere to show the result. Every Logdash monitor can sit on a public status page, and the free plan includes one, so customers see the outage before they write to you about it.

What does an API uptime checker actually check?

In Logdash, the status code and whether a reply arrived within 10 seconds. 200 to 399 is up, everything else is down. Response time is recorded and charted on every check but does not trigger an alert on its own.

Is there a free API uptime checker?