API monitoring that catches the wrong answer.

Your health endpoint can't see a broken login flow. Uptimia signs in, calls the API and checks the answers — so you get the failing step, not a support ticket.

Start free trial → View pricing
30-day free trial · up to 50 API monitors No credit card GDPR-ready
Check interval
60s
Locations to confirm
3
Checkpoints
171+
Countries covered
70+

Step 4 returned 500

A five-step order flow, run on schedule. Login, the order lookup and the total all pass — the request that follows them does not.

step 1 Log in — take the tokenPOST /auth/login returns 201; the bearer lands in {{token}} you: undisturbed
steps 2–3 Call the API with itGET /orders grabs {{order_id}}; the order must show the right total you: undisturbed
step 4 POST /orders/{{order_id}}/notes → 500The assertion fails and names the gap: expected 201, got 500 you: undisturbed
14:32 Confirmed elsewhere — then you're pagedOther locations re-run and agree; the alert already says step 4 paged: with the cause
step 4named in the alert
"Expected 201, got 500."14:32
That's the whole hunt, done before you opened your laptop: the step, the assertion, and confirmation it isn't one probe's bad night. The fix starts at the failing request — not at "the API is down".
failing step namedexact assertion quotedconfirmed from other locationsstatus · timing · headers · JSON — per step
And with only a ping? /health returns 200 the whole time — a broken step deep in the flow never touches it. The first report is a customer who couldn't finish, and a hunt through logs to find where it broke. found by a customer

What a ping never sees

A 200 that returns the wrong data is still a failure, and a broken step three requests deep never touches your health endpoint. Point one monitor at your own API — or at the vendor APIs you depend on, and know it's them, not you.

Status codes & headers2xx asserted · headers checked
JSON body values$.order.status asserted per step
Mid-workflow 500sStep 3 fails — a ping never sees it
Payload driftWrong shape, missing fields
15 steps per chain the whole workflow, run for real
Auth breaks401s and expired tokens
TLS & connect errorsHandshakes and refused sockets
Response-time budgetEvery step under its limit
Alerts name the step and the assertion that failed: an HTTP 4xx or 5xx, a wrong JSON value, a missing field, a slow step, a TLS error or an auth failure. step + assertion

Chains, assertions and timing

The workflow

Chain up to 15 requests

Each step can pull a value out of the response — a token, an order id — into a variable that later steps drop in as {{name}}. One monitor covers the journey from login to clean-up.

  • 6 HTTP methods — GET, POST, PUT, PATCH, DELETE or HEAD, in any order
  • Extract into variables — reference them anywhere downstream as {{name}}
  • Custom headers, body and per-step timeout — duplicate a step to build fast
Drive a real browser through the same flow →
POST/auth/login1 assert
{{token}}extracted → later steps
GET/orders2 asserts
{{order_id}}
GET/orders/{{order_id}}3 asserts
POST/orders/{{order_id}}/notes1 assert
DEL/sessions/{{token}}clean up
Chain passed1.94 s
One monitor runs the whole journey — login to clean-up — as often as every minute.
5 steps7 assertions2 variables
A step with no assertions still passes on any 2xx — add checks only where they matter. any 2xx
Assertions

Assert on status, JSON and timing

Add the checks a step must pass: an exact status, a response-time budget, a value in the JSON body, a header, or text in the response. When one fails, the run shows what it got — and Run test hits the real endpoint before you save.

  • Status and response time — the step fails if the code is wrong or the response is too slow
  • Values inside the JSON — point at a field and require it to be there, and to be right
  • Response headers and body text — checked on the probe, before results are stored
Watch for text on a page, not just a status →
Run test200 · 191 ms
GET /orders/8842 · step 3 — the live response, hit for real before you save.
{
  "id": 8842,
  "status": "paid",
  "total": 4210
}
status is 200got 200
$.status equals "paid"got "paid"
response time under 500 msgot 191 ms
Extracted {{order_id}} = 8842 feeds the next step — highlighted in the live response above. = 8842
Timing

DNS, TLS or your own backend

"The API is slow" is never the whole story. Every step's time is split into five phases — DNS, connect, TLS, wait, receive — so you see which step is dragging and whether the network or your backend is behind it.

  • Five-phase timing per step — DNS, connect, TLS, wait, receive
  • Response-time-by-step chart — stacked, with incident markers
  • Slowest step and slowest runs surfaced on the monitor detail page
Phase-by-phase timing for web pages →
Step 4 — slow14:32:16
POST /orders/8842/notes · 1,389 ms total, split into five phases.
dns18 ms
connect31 ms
tls44 ms
wait1,284 ms
receive12 ms
Network — fine
dns 18 · connect 31 · tls 44
93 ms
Backend — the drag
think-time before the first byte
1,284 ms
Slowest step and slowest runs sit on the monitor page — a stacked per-step chart shows when the drag began. slowest
Secrets

Real API keys, kept masked

Store passwords, API keys and tokens as secret variables: write-only, masked on read, and redacted from echoed URLs, headers and response snippets. Nothing sensitive ends up in your run history.

  • Write-only secret variables — masked whenever they're read back
  • Redacted everywhere it's echoed — URLs, headers and body snippets
  • Extracted values that match a secret are never echoed either
Monitoring pages behind a login →
API_KEYsecret
••••••••••••••••write-only
Stored once, never shown again — a read returns value:'' · has_value:true.
Step 1 header — what you configure
Authorization: Bearer {{API_KEY}}
real key injected at send time — memory only, never stored
Run history — what gets stored
Authorization: Bearer [redacted]
Extracted values that match a secret are never echoed either — nothing sensitive lands in run history. masked

Chain the requests once.Get the failing step named.

Every step, every assertion, every alert channel — free for 30 days, and none of it is a paid add-on.

Start your free 30-day trial →
30 days free no credit card cancel anytime

How API monitoring works

Build the chain, prove it against the live API, then Uptimia runs it on a schedule from our network — nothing to install.

Step 1build it

Chain your requests

Add each request in order, set headers and body, and extract the values later steps need into variables.

Step 1 · request
POST /auth/login
extract $.token → {{token}}
Step 2 · request
GET /orders
Step 2prove it

Assert and run a test

Add the checks each step must pass, then Run test against the real endpoint — full per-step results, before you save.

Assertions · step 3
status is 200$.status = "paid"
under 500 ms
Run test · 5/5 steps passed in 1.9 s
Step 3every minute

We run it on schedule

A probe runs the whole chain in one round trip, checks every assertion, and stores per-step results — failures are confirmed from other locations before alerting.

Run OK — 5/5 steps
14:31 · 1.8 s · all assertions passed
on time
Run failed — step 4
14:32 · expected 201, got 500
alerting

Also included

Slack, PagerDuty, SMS and 9 more

An API alert names the failing step and cause, delivered on the same contacts every Uptimia monitor uses — email, SMS, Slack, Teams, Discord, PagerDuty, webhooks and more.

step 3 · $.status: expected "paid", got "pending" → Slack · Email · PagerDuty

Confirmed from other locations before it pages

A failed run is re-tried from other capable locations first.

re-run elsewhere · agreed before it opens

Duplicate a step

Build a long chain fast — copy a request and tweak it.

step 3 → duplicate → step 4

Incident RCA export

A closed incident keeps the step-level detail — export it.

RCAPDFHTML

Timeout, headers and body per request

Give every request its own timeout, headers and payload.

timeout 10 s · 20 headers · 64 KB body

Every monitor type in one account

Your API monitors sit beside uptime, SSL, heartbeat and DNS monitors — same contacts, groups and roles.

Checkout order flowAPI www.caldmont.comUPTIME db-backup · nightlyHEARTBEAT

What is API monitoring?

API monitoring is an automated service that runs a real sequence of HTTP requests against your REST API or JSON endpoint on a schedule and alerts you when a step returns the wrong status, the wrong data, or takes too long. It watches the workflow behind an endpoint, not just whether the server answered.

While everything works

How does API monitoring work?

Uptimia
runs the chain
5 steps · on schedule
Your API
200 · asserts pass

A probe runs every step in one round trip, evaluates each assertion, and stores the per-step results as your run history.

When a check fails

Confirm first, then alert

Your API
step 4 · 500
re-run · other locations
Uptimia
opens the incident

step 4: expected 201, got 500 → incident opens, alert names the step

The checks

What does an API monitor verify?

A step passes on any 2xx by default. Add assertions and the run must prove them — an exact status, a response-time budget, a JSON value, a header, or body text.

Free tool: check any endpoint's status & headers →
CheckWhat it provesExample
Status codethe endpoint answered as expectedis 201 · is one of 200/204 · any 2xx
Response timethe step is fast enoughunder 500 ms
JSON bodythe response holds the right data$.status equals "paid"
Headerthe right content type or cache ruleContent-Type contains json
Body texta marker is present or absentcontains "order created"

API monitoring FAQ

01What is API monitoring?+
An automated service that runs a real sequence of HTTP requests against your API on a schedule and checks the responses. One Uptimia monitor chains up to 15 requests and alerts you when a step returns the wrong status, the wrong data, or takes too long. You'll also see it called synthetic API monitoring or an automated API health check.
02How is this different from a simple uptime ping?+
A ping tells you the server answered. API monitoring runs the whole workflow and checks the response itself — status code, response time, headers and the values in the JSON. A 200 that returns the wrong data is caught here and invisible to a plain ping.
03How often does Uptimia run my API check?+
By default every 5 minutes, and as often as once a minute — the scheduling sweep runs per minute, so one minute is the floor. You can also slow any monitor down for lower-priority endpoints.
04How many steps can one monitor have?+
Up to 15 HTTP requests in a single chain, each with up to 20 headers, 15 assertions and 10 value extractions. Per-step timeout runs from 1 to 60 seconds, and the whole chain has a 90-second run budget.
05Does it run JavaScript or render the page like a browser?+
No. API monitoring sends plain HTTP requests — no headless browser, no JavaScript, no screenshots. To drive a real browser through a rendered flow, use Uptimia's transaction monitoring; API monitoring is the leaner, faster tool for the API itself.
06Can I check a value inside the JSON response?+
Yes. Point a JSONPath selector at the field and assert it exists, equals, contains, or is one of a set. You can also extract a value into a variable and reuse it in later steps as {{name}}. JSONPath support is a focused subset for typical API responses.
07Do you support GraphQL or WebSockets?+
GraphQL works as a plain HTTP POST — send the query in the body and assert on the JSON that comes back — but there's no GraphQL-specific builder. WebSockets aren't supported; API monitoring covers request/response over HTTP (GET, POST, PUT, PATCH, DELETE, HEAD).
08Can I import a cURL command or start from a recipe?+
Not in this version. You build each step in the editor — method, URL, headers, body, assertions, extractions — and can duplicate a step to move fast. cURL import and a recipe library aren't part of API monitoring yet.
09How do you avoid false alarms?+
A failed run is re-run from other locations before an incident opens — by default three locations must agree (the original plus two re-runs) before you're paged. Recovery is quick the other way: a single passing run closes the incident and sends the recovery notice.
10Are my API keys safe inside a check?+
Yes. Store credentials as secret variables: write-only, masked on read, and redacted from echoed URLs, headers and response snippets — nothing sensitive lands in your run history.
11Is API monitoring a paid add-on?+
No. Every plan includes API monitoring alongside uptime, SSL, transaction, DNS and heartbeat monitoring — never as a paid add-on. Even the free plan comes with one API monitor; plans differ only in how many are included, and the 30-day free trial includes up to 50, no credit card needed.

Start monitoring your API today.

Build the chain, prove it against the live endpoint — and the next time a step breaks, the alert already tells you which one.

Monitor your API →
30-day free trial Up to 50 API monitors No credit card EU-hosted, GDPR-ready
API monitoring joins uptime, SSL, speed, transaction, DNS and heartbeat monitoring under one Uptimia login.