Prove client API reliability with proactive monitoring

An API monitor calls one endpoint with the method, headers, JSON body and auth you configure, then scores the response against the status codes you accept and the response time you allow.

No card required · 50 monitors free · No time limit

Monitoring/https://api.acmecorp.com/v1/orders

https://api.acmecorp.com/v1/orders

API monitor · checked every 60s

Mute 1h Mute 24h Export CSV
Current Status
ISSUE
HTTP 502 — outside policy
Avg. Response (24h)
342ms
Fast
Fastest Check
96ms
Fastest in the selected window
Uptime (30d)
99.94%
Reachability, last 30 days
OverviewFailed checksConfigurationAlerts & contactsMaintenance

Configuration

Monitor TypeAPI
HTTP methodGET
Accepted status codes200, 201
Response Threshold2000ms
API ConfigCustom HeadersCustom Body

Failed checks 3 in the last hour

09:41:07HTTP 5021204 ms
09:40:07HTTP 5021187 ms
09:39:07HTTP 5021240 ms
09:38:07HTTP 200318 ms

Why this is an issue and not downtime

The endpoint answered — it is reachable. It answered 502, which is outside the accepted status codes, so ErrorDetector records a failed check. Uptime stays honest; the alert still fires.

Maintenance value

Why this matters
for client care

Each feature earns its place by making the client relationship easier to protect: fewer surprises, clearer proof, and faster explanations when something changes.

01

You define what "healthy" means

List the status codes this endpoint is allowed to return — 200, 201, 204, whatever it actually answers with — and a response-time limit in milliseconds (2000 ms unless you change it). A response outside either rule is a failed check.

02

The request your API expects

Choose HEAD, GET, POST, PUT, PATCH or DELETE, add request headers as JSON for a bearer token or API key, send a JSON request body, and supply Basic auth credentials where the endpoint needs them.

03

Response time on every single check

Each check records how long the endpoint took, in milliseconds. Slow drift shows up on the monitor’s history long before the endpoint starts returning errors.

04

Historical uptime reports

Prove SLA compliance with up to 24 months of uptime history on paid plans. Every month ErrorDetector e-mails you a client-ready uptime report you can forward as it is.

How the result is scored

Why a rejected response shows as an Issue, not Down

Every call records two separate things: whether the endpoint answered at all, and whether the answer passed your rule. Mixing those two is how an uptime figure ends up lying to a client.

Up

Shown as “Passing”

The endpoint answered with a status code you accept, inside your response-time limit.

Issue

Shown as “Failed check (HTTP 503)”

The endpoint answered — there is a status code and a response time — but it fell outside your accepted codes, returned a 4xx or 5xx, or came back slower than your limit. The API is reachable, so this is not downtime. The alert names the reason, and your uptime percentage is untouched.

Down

Shown as “Down”

Nothing answered: the connection timed out or was refused, the name did not resolve, or TLS failed. That is a reachability failure — it opens an incident and it is the only thing counted against uptime.

Both states alert through every channel on the monitor. Only Down opens an incident and moves the uptime number, so ninety seconds of 503s during a deploy is reported as what it was: a failed check on a server that never went away.

Real examples

What clients and developers actually see

Concrete moments from the feature: setup, the signal that matters, and the client-facing proof that makes maintenance feel easy and valuable.

Monitor setup · example data

One endpoint, one policy

Method, headers, request body and the status codes you accept — everything the check needs.

Method

POST

Accepts

200, 201

Endpoint

https://api.acmecorp.com/v1/orders

HTTPS

Request headers

Authorization: Bearer *** · Content-Type: application/json

Sent

Request body

{"sku": "AC-1042", "qty": 1}

JSON
Save monitor Check every 60s

Live result · example data

HTTP 503 is a failed check, not an outage

The endpoint answered, so uptime is untouched. The policy failed, so you still get told.

Response time

184 ms

Policy

Failed

POST /v1/orders

HTTP 503 is not in this monitor’s accepted status codes

Issue

Reachability

The host answered in 184 ms — the uptime bar stays green

Up

Alert

Sent after 3 failed checks in a row, so a deploy blip stays quiet

Sent
Retry streak 3 of 3 Response threshold 2000 ms

Client proof · example data

The monthly uptime e-mail

One month of recorded reachability, with the failed policy checks listed separately.

30-day uptime

99.98%

Report

E-mailed

Uptime

Measured from recorded reachability only

99.98%

Failed checks

Responses outside 200, 201 during the month

12

Slowest response

Recorded 03:12 UTC on the orders endpoint

1 842 ms
Forward to the client Public status page
Quick start

Setup for one client in seconds

Add the signal once, then let alerts, history, and reports build automatically.

Step 1

Add the endpoint

Paste the API URL and pick the HTTP method the endpoint expects.

Step 2

Describe the request

Add request headers as JSON, a JSON body if the endpoint needs one, and Basic auth credentials where they apply.

Step 3

Set the pass rule

List the status codes you accept and the response time above which the check should fail.

Step 4

Monitor and report

ErrorDetector calls the endpoint on your plan interval, alerts your channels, and e-mails a client-ready uptime report every month.

FAQ

Frequently asked questions

Any HTTP endpoint — REST and GraphQL are the everyday cases. The request body is sent as JSON, so an endpoint that insists on an XML or form-encoded body cannot be given one; you can still monitor it with a GET or HEAD request and score it on the status code and response time.

Not on an API monitor. The pass rule there is the status code plus the response-time limit. If you need to assert on what came back, point a keyword monitor at the same URL — it searches the response text for a string you choose.

Within a check interval of the failure being confirmed. Solo and Team plans check every 60 seconds; the Enterprise plan checks every 30 seconds. By default a monitor has to fail three checks in a row before it says anything, so a single deploy blip stays quiet.

Yes. API, keyword, cron, DNS and SSL monitors live in the same dashboard and share the same alert channels. Paid plans unlock every monitor type; the Free plan covers HTTP monitors only.

Everything else

Everything around the client website

Combine uptime, SSL, domains, incidents, alerts, teams, and reports into one maintenance workspace.

Make this part of your maintenance service.

Start with api monitoring and build client trust with real data. Free, no credit card required.

Create free account

No card required · 50 monitors free · No time limit