Monitoring endpoints that need a login

The endpoints most worth monitoring are usually the ones behind a login. Your public marketing page going down is embarrassing; your billing API going down costs money — and you cannot check it by fetching a URL anonymously.

Every HTTP monitor has an Authentication section on its create and edit form, with four options.

Basic and bearer — for credentials that don’t expire

Pick Basic for a username and password, or Bearer token for a static API key. We send the matching Authorization header on every check.

Tip

Every credential you enter here is encrypted at rest, and shown back to you as *** afterwards. Even so, prefer a read-only credential scoped to a health endpoint over an admin one — least privilege costs you nothing here.

The catch with a bearer token is that most modern APIs don’t issue permanent ones. You paste a token, the monitor is green for an hour, and then it is red forever — not because your API broke, but because the token expired. That failure looks exactly like a real outage, which makes it the worst kind.

OAuth2 — for tokens that expire

Pick OAuth2 (client credentials) and give us the same credentials your own services use. Before each check we request a fresh access token from your provider, cache it until shortly before it expires, and use it to make the actual request. You are alerted about your API, never about your token.

You need three things, all from your identity provider’s application settings:

Field	What it is
Token endpoint URL	Where tokens are issued, e.g. https://login.example.com/oauth2/token. Must be https.
Client ID	The machine-to-machine application’s identifier.
Client secret	Its password. Encrypted at rest; shown as *** afterwards.

And two optional ones:

• Scope — if your provider needs the token to be scoped, e.g. read:health.
• Extra parameters — one key=value per line. Auth0 requires audience=https://your-api; some providers want resource. Most need nothing here.

Tip

If the token request is rejected, change Credentials sent as. Providers accept the client credentials either in the Authorization header or in the request body, and not always both. The header is the standard and our default; switching to the body fixes most “invalid client” rejections.

This uses the client credentials grant — the machine-to-machine one. It needs no browser, no user, and no refresh tokens. If your provider only issues tokens through a login screen, that flow can’t be automated by anything, including us; issue a service application instead.

When the token has to be fetched first

The four options above cover credentials you can hand us up front. If your API mints a token per session — you POST to /login, read a token out of the reply, and send it on the next request — that is a multi-step sequence rather than an authentication setting.

What happens when something goes wrong

Getting a token is part of the check, so a token failure is a down result with a specific reason rather than a silent skip. We never report a monitor as up when we couldn’t authenticate — a green check you can’t trust is worse than no check.

What you’ll see	What it means
The login server rejected our credentials	Your client ID, secret, scope or audience is wrong or revoked. Check the exact status code shown.
Couldn’t reach the login server	The token endpoint itself is down or unreachable — worth a monitor of its own.
The login server’s response didn’t contain an access token	The endpoint answered, but not with a token. Usually the wrong URL — an authorize endpoint instead of a token endpoint.

If your API rejects a token we thought was still valid — because it was revoked early — we fetch a new one and retry once, automatically, before reporting anything. A rotation on your side doesn’t page you.

Rotating a secret

Open the monitor, type the new secret over the ***, and save. Leaving *** untouched keeps the stored one, so you can edit anything else on the form without re-entering credentials.

Cost

Nothing. Authentication is on every plan, including free. A token is fetched once per token lifetime rather than once per check — a one-hour token on a one-minute monitor means one extra request per sixty checks.