Monitoring a Site Behind a Login

A staging site or a pre-launch site is often protected by HTTP basic auth, or by a firewall that only lets in requests carrying a secret header. Your monitor's checks need a way past that login, or they only ever see the login page.

Site access is that way. You set it once per monitor, and every check that requests the site uses it.

Set it up

1. Open the monitor and go to the Settings tab.
2. In Site access, switch on HTTP basic auth and enter the username and password, and/or add access headers (for example X-Access-Token: …).
3. Click Save. The checks use it from their next run. Run now on a check shows the result right away.

Which checks use it

Uptime (including the verification from a second location), robots.txt, sitemap, redirects, security headers, mixed content, GEO audit, application health, broken links and Lighthouse.

SSL, DNS, domain expiry, DNSBL, TCP, ping and Core Web Vitals never request your pages, so they don't need it.

The uptime check can have its own basic auth and headers in its settings. They replace the monitor's site access for that check only, for example when the uptime check calls a health endpoint with different credentials.

Where it is sent, and where not

Site access is sent only to your monitor's own address: the same scheme, host and port as the monitor URL (https://staging.example.com). Every request is checked on its own:

• A redirect to another host never gets it. Neither does a downgrade from https to http on the same host.
• Lighthouse loads your page in Chrome. Third-party resources the page loads (fonts, analytics, a CDN) never get your credentials, and Chrome answers a login challenge only when it comes from your site.
• The broken-links crawler sends it to pages on your site only, never to external links.
• A check that retries without certificate verification (after a certificate error) doesn't send it.

Stored safely

The password and every access-header value are encrypted at rest and never shown again: the dashboard and the API show ********. Sending ******** back keeps the stored value. Data exports show them masked as well.

What the results say

Result	Meaning
Couldn't test: the site asks for a login (HTTP 401)	The site needs a login and the monitor has no site access. No alert, and the run doesn't count in any figure. Add site access.
The site rejected the site access of this monitor (HTTP 401)	Site access was sent, but the site refused it. The password probably changed. This is a normal warning.

API and MCP

Site access is the site_access field of a monitor: PATCH /api/v1/monitors/{id} with

{
  "site_access": {
    "http_auth": { "username": "staging", "password": "…" },
    "headers": { "X-Access-Token": "…" }
  }
}

null removes it, and "http_auth": null removes only the basic auth. The MCP tool update-monitor accepts the same field. Reading it always returns the masked values.