Checking a sequence, not just a URL

An ordinary HTTP monitor makes exactly one request. That is fine for “is the homepage up”, and useless for the thing most people actually want to know: can a customer log in and see their orders?

Checking that takes two moves. Sign in and get handed a token, then use that token to open the real door. A multi-step HTTP check does both, in order, and carries the token between them.

Note

If your credentials are a static API key or a username and password, you do not need this — an ordinary HTTP monitor has an Authentication section that sends the header for you. Reach for a sequence when the token is minted per session: you have to call a login endpoint to get one.

What a step is

A step is an ordinary HTTP check — method, URL, headers, body, and the same response checks a single-request monitor has — plus one extra ability: it can keep a value from the reply.

Steps run in order and stop at the first one that fails. There is no point calling /orders if /login just returned a 500.

Keeping a value, and using it

On any step, add an entry under Keep from the reply:

Field	What it does
Name	What you will call the value later, e.g. token
Where from	JSON field, Response header, Status code, or Whole body
Path	For JSON, a path such as data.access_token. For a header, its name
Secret	Tick it for anything credential-shaped

Then use it in a later step by writing {{token}} — in the URL, in a header value, or in the body:

Step 1  POST https://api.example.com/login
        Keep: token  ←  JSON field  data.access_token  (secret)

Step 2  GET  https://api.example.com/orders
        Header: Authorization: Bearer {{token}}
        Check:  response.json.orders is not empty

Two built-in values are always available without keeping anything: {{$timestamp}} (seconds since the epoch) and {{$uuid}} (a fresh random id). Both are regenerated for every request, which is what APIs with replay protection expect.

Caution

A value can only be used by a step after the one that kept it. Referring to one from an earlier position, or misspelling it, fails the check rather than sending the literal {{token}} text to your server — because an endpoint that receives nonsense often answers 200 OK while doing nothing, and a monitor that reports green on a broken login is worse than no monitor at all. The editor lists what is available at each step so you can see this before saving.

Tick “Secret” on anything credential-shaped

It costs nothing and it changes what can leak. A value marked secret is scrubbed out of failure messages, out of the stored step breakdown, and out of our logs — by its value, not its name. That matters because a server rejecting a token frequently quotes it back at you ({"error":"invalid token eyJhbGci…"}), and that reply is exactly what ends up in a failure message.

Cookies are handled for you

Plenty of logins hand back a session cookie rather than a token in the body. We keep those for the length of the sequence and send them back automatically, so step 2 arrives authenticated without you configuring anything.

Cookies are only ever replayed to the host that set them. If your login redirects to a dashboard, the cookie is set during the redirect — turn off Follow redirects on that step so we can see it.

The time limit, and why it is shared

The whole sequence shares one time budget, not one per step. It is the smaller of 60 seconds and half your check interval — so a monitor checking every 5 minutes gets the full 60 seconds, and one checking every minute gets about 30.

The half-interval part is not a preference. A failing check is re-tried once to confirm before we believe it, so a sequence that ran longer than half the interval would still be running when its own next check started.

If a sequence runs out of time it is reported as down, with a message naming the step it was on. That is deliberate: a service that hangs indefinitely is a worse outage than one returning errors quickly, and treating it as a gentler problem would mean the worst failures woke nobody.

Ten steps is the maximum, for the same reason. If you need more, that is two monitors — and honestly, a minute-long business process is not an uptime check.

When it breaks, you get told where

A sequence stops at its first failing step, so “this monitor is down” would not be much help. The monitor page shows the run instead:

	Step
1	sign in	passed	HTTP 200 · 84 ms
2	fetch orders	failed	HTTP 401
3	check totals	not run

Steps after the failure say not run, not “failed” — they were never contacted, and we are not going to imply their endpoints are broken.

What it costs

A sequence costs the same as a single check on your plan. A five-step chain is one check run, not five.

That is worth stating plainly because it is not how everyone does it. Checkly’s pricing page says of their Multistep Checks: “Each request counts as one run. For example, if your Multistep Check script makes 3 requests, then that counts as 3 runs each time your check executes.” (checked 5 September 2026). Ours counts as one, because our costs genuinely do not scale with the request count.

Multi-step checks are available on Pro and above.