How to Set Up API Monitoring (Step by Step)

Tests run before you ship. Monitoring runs forever after. An API can pass every test in CI and still go down at 3 a.m. because a certificate expired, a dependency timed out, or a deploy quietly broke a response shape. API monitoring is how you catch those failures before your users open a support ticket. This guide explains the layers of API monitoring, walks through setting up checks with popular tools, and shows how to build alerting that wakes you up only when it should.

What API monitoring is - and how it differs from testing

Functional and load testing happen in a controlled environment before release. Monitoring is continuous, automated checking of your live API from the outside, on a schedule, around the clock. The two complement each other: tests prove the code is correct when you write it; monitoring proves the running system stays correct, available, and fast in production.

Good API monitoring answers three questions on a loop:

• Is it up? Does the endpoint respond at all?
• Is it fast? Is latency within your service level objective?
• Is it correct? Does the response have the right status code, shape, and data?

The layers of API monitoring

Monitoring is not one thing. Most mature setups stack several complementary layers:

• Uptime checks. The shallowest layer: ping an endpoint on a short interval and confirm it returns a healthy status code. Cheap, fast, and great for a status page - but it only tells you the lights are on.
• Synthetic monitoring. Scripted, multi-step transactions that mimic a real user - log in, create a resource, read it back - and assert on the response bodies. This tells you the building actually works, not just that the door opens.
• Latency and SLO tracking. Recording response-time percentiles over time so you can alert on degradation, not just hard failure. A p95 creeping from 200 ms to 900 ms is a warning you want before it becomes an outage.
• Multi-region checks. Running probes from several geographic locations so you can tell a genuine outage from a single flaky region or network path.

Setting up monitoring, layer by layer

1. A do-it-yourself uptime check

The simplest possible monitor is a scheduled curl that exits non-zero when the API is unhealthy. Drop this in a cron job or a CI scheduled pipeline to get started in minutes:

# fail with a non-zero exit if the API is not healthy
http_code=$(curl -s -o /dev/null -w '%{http_code}' \
  --max-time 5 https://api.example.com/health)

if [ "$http_code" -ne 200 ]; then
  echo "health check failed: HTTP $http_code"
  exit 1
fi
echo "healthy"

This is fine for a hobby project, but it runs from one place, has no history, and no alerting. For anything real you will want a dedicated tool.

2. Uptime monitoring with a hosted service

Services like UptimeRobot and Better Stack ping your endpoints from multiple regions every minute, keep a history of incidents, render a public status page, and notify you on failure. Setup is usually point-and-click: paste the URL, choose an interval, pick alert channels. They are the fastest way to get reliable availability monitoring and a status page without writing code.

3. Synthetic monitoring with Checkly

Checkly is a code-first synthetic monitoring platform. You write checks as JavaScript and Playwright tests, version them alongside your application, and Checkly runs them on a schedule from regions you choose. A check asserts on availability, latency, and correctness in one place:

const { test, expect } = require('@playwright/test');

test('orders API returns a list', async ({ request }) => {
  const res = await request.get('https://api.example.com/v1/orders', {
    headers: { Authorization: `Bearer ${process.env.API_TOKEN}` },
  });

  // availability + latency
  expect(res.status()).toBe(200);

  // correctness
  const body = await res.json();
  expect(Array.isArray(body.data)).toBe(true);
  expect(body.data.length).toBeGreaterThan(0);
});

Checks are configured with a frequency, locations, alert channels, and latency thresholds - often as code, so the whole monitor lives in your repo. The exact syntax varies by tool; conceptually the settings look like this:

checks:
  orders-api:
    frequency: 60          # run every 60 seconds
    locations:
      - us-east-1
      - eu-west-1
    alertChannels:
      - slack
      - pagerduty
    degradedResponseTime: 500   # warn over 500ms
    maxResponseTime: 2000       # fail over 2000ms

Because the check runs the same kind of request and assertions you would write while developing, synthetic monitoring is essentially your functional tests, promoted to run forever against production.

4. Synthetic monitoring inside an observability platform

Datadog and New Relic bundle synthetic API monitoring into their broader observability suites. The advantage is correlation: when a synthetic check fails, you can pivot straight to the traces, logs, and infrastructure metrics from the same incident. If your team already runs one of these platforms, adding API monitors there keeps everything in one pane of glass.

5. Self-hosted monitoring with Prometheus

If you prefer open source and want to own your data, the Prometheus stack with the Blackbox Exporter probes HTTP endpoints and records the results as metrics. You point a scrape job at the exporter:

# prometheus.yml - scrape an HTTP probe via the Blackbox Exporter
scrape_configs:
  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://api.example.com/health
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Then define an alerting rule in Prometheus (Alertmanager then routes and delivers it) that fires only after the probe has failed for a sustained window, which avoids paging on a single transient blip:

# prometheus alerting rule: page if the probe has failed for 2 minutes
groups:
  - name: api-availability
    rules:
      - alert: ApiDown
        expr: probe_success == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: 'API health probe failing for {{ $labels.instance }}'

Building alerts that work

A monitor with bad alerting is worse than no monitor: if every blip pages the team, people mute the channel and miss the real outage. Build alerting that earns trust:

1. Alert on symptoms, not noise. Page on conditions a user would actually feel - the API is down, or p95 latency has crossed your SLO - not on a single slow request.
2. Require confirmation. Only fire when a check fails from multiple locations, or for two consecutive runs, so one flaky region does not wake anyone.
3. Tier your severities. Route low-severity warnings to a chat channel and reserve phone or pager escalation for genuine outages. Not every alert deserves to break someone’s sleep.
4. Make alerts actionable. Every alert should say what failed, where, and ideally link to a runbook. An alert that just says “something is wrong” wastes the responder’s first five minutes.
5. Review and prune. Periodically delete alerts that never fire usefully and tune thresholds that fire too often. Alert hygiene is ongoing work.

Where Requestly fits in

Requestly API Client is a Git-native desktop API client for REST, GraphQL, and SOAP. It gives you collections, environments and variables, pre- and post-response scripting, and assertion-based tests using rq.test and rq.expect - all running on your machine. Those assertions are precisely what a synthetic monitor runs in production, so Requestly is the natural place to design and validate the checks: build the request, nail the auth, and write the assertions against the response, then carry that same logic into your monitoring tool.

Scheduled, hosted API monitoring is on our roadmap and is not a shipped feature yet. Until it lands, the practical path is to author and test your requests and assertions in Requestly, then run continuous monitoring with Checkly, UptimeRobot, Datadog, or a self-hosted Prometheus stack.

If you are building out a full testing strategy, see our companion guides on API load and performance testing, testing WebSocket APIs, and testing gRPC services. For a wider tool landscape, our roundup of the best API testing tools is a good starting point.

Try Requestly API Client: A Git-native desktop API client for REST, GraphQL, and SOAP - with collections, environments, scripting, and assertion-based tests (rq.test / rq.expect) that run fully on your machine. Download Requestly →

Frequently asked questions

What is API monitoring?

API monitoring is the continuous, automated checking of an API in production to confirm it is available, fast, and returning correct data. Rather than testing once before release, monitors run on a schedule from outside your system and alert you the moment availability, latency, or correctness drifts outside acceptable bounds, so you find problems before your users do.

What is the difference between uptime and synthetic monitoring?

Uptime monitoring is a shallow check that an endpoint is reachable and returns a healthy status code, usually a simple ping every minute. Synthetic monitoring is deeper: it runs a scripted, multi-step transaction such as log in, create a resource, then read it back, and asserts on the response bodies. Uptime tells you the lights are on; synthetic tells you the building actually works.

Which tools can I use for API monitoring?

Checkly is popular for code-first synthetic checks written in JavaScript and Playwright. UptimeRobot and Better Stack cover lightweight uptime and status-page needs. Datadog and New Relic provide synthetic monitoring tied into full observability platforms. For self-hosted setups, Prometheus with the Blackbox Exporter and Alertmanager is a common open-source stack.

How often should I run API monitoring checks?

Match the frequency to how critical the endpoint is. Core revenue paths such as login or checkout are often checked every minute from several geographic regions, while less critical endpoints might be checked every five or ten minutes. More frequent checks detect outages faster but cost more in run minutes, so reserve the tightest intervals for the routes that hurt most when they fail.

How do I avoid alert fatigue?

Alert on symptoms users feel rather than every transient blip, require a check to fail from multiple locations or for two consecutive runs before paging, set thresholds against latency percentiles instead of single slow requests, and route low-severity issues to a chat channel while reserving phone or pager escalation for genuine outages. Clear, actionable alerts keep on-call engineers responsive.

Does Requestly offer API monitoring?

Requestly is a local-first API client for REST, GraphQL, and SOAP, with collections, environments, scripting, and assertion-based tests. Scheduled, hosted API monitoring is on our roadmap and not yet shipped. For now we recommend Checkly, UptimeRobot, or Datadog for production monitoring, and Requestly for designing and functionally testing the requests and assertions those monitors will later run.