---
title: "API uptime monitoring with Telegram alerts | Logdash"
description: "What an API uptime check asserts, why it needs a public health route, and how to get a Telegram alert within 5 minutes, 1 minute or 15 seconds."
url: https://logdash.io/monitoring/api
---

# 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 

```javascript
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

1. **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.
2. **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.
3. **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? 

Yes. Logdash checks 5 services every 5 minutes for free, with Telegram alerts and one public status page. If the check needs a token or a JSON body assertion, the free Checkly Hobby plan gives 10,000 API check runs a month.

## Keep reading

[All monitoring guides](https://logdash.io/monitoring): One page per thing you run, each with the code that makes it checkable and the monitor that watches it.

[REST API monitoring](https://logdash.io/monitoring/rest-api): REST API monitoring means requesting one public GET route that touches the same database your endpoints use, on a fixed interval from outside your servers, and alerting on any status outside 200-399, which the free plans of Logdash, UptimeRobot and Better Stack all do.

[Website uptime monitoring](https://logdash.io/monitoring/website): Website uptime monitoring requests your site on a schedule, every 5 minutes on a free plan, and alerts you the moment it answers with an error or stops answering, so you hear about downtime before a visitor emails you.

[Webhook monitoring](https://logdash.io/monitoring/webhook): Monitor a webhook receiver with an uptime check on a GET route at the same path, because providers only ever POST to it, and monitor the jobs behind it with a push monitor they call like an inbound webhook, so a missing call becomes an alert.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.