Most website monitoring tools have the same blind spot: they only work on pages anyone can visit. Public marketing sites, pricing pages, docs. The moment a page requires a login, they stop working.
That is a significant gap. Some of the most valuable pages to watch are behind authentication. A competitor's customer portal might show pricing tiers that never appear on the public site. An internal dashboard might have metrics your team needs to track. A supplier might publish stock or pricing information in a protected area only customers can see.
Here is how authenticated monitoring works, and how to set it up.
Why most tools cannot do this
Standard uptime and content monitoring works by making an HTTP request to a URL and checking what comes back. For a public page, that is straightforward. For a page behind a login, the server sees an unauthenticated request and does one of two things: it redirects to a login page, or it returns a completely different page with no useful content.
The monitor sees a redirect or a login form. It has no idea what the real page looks like, so it cannot detect changes to it.
The session cookie approach
When you log in to a website, your browser receives a session cookie. Every subsequent request your browser makes to that site includes that cookie in the request headers. The server checks it, recognises you as authenticated, and returns the page you asked for.
A monitor can do the same thing. If you paste your session cookie into the monitor's configuration, it sends that cookie with every check. The server sees an authenticated request and returns the real page. The monitor can then watch that page for changes exactly as it would a public one.
This approach is practical for most use cases. No credentials are stored, no passwords, no login flow to automate. You give the monitor a token your browser already has.
How to get your session cookie
- Open the site in your browser while logged in
- Open DevTools (F12 or right-click and Inspect)
- Go to the Network tab
- Reload the page, or click any link on the site
- Click on any request to that domain in the list
- Find the Request Headers section
- Look for the Cookie header and copy its value
The value looks something like session=abc123xyz; _csrf=def456; other=value. Paste the whole thing into the Session Cookie field on your monitor.
What about expiry
Session cookies expire. When they do, the server starts returning the login page again instead of the real page. Your monitor will likely detect this as a content change, since the page content will have shifted entirely.
When that happens, repeat the steps above to get a fresh cookie and update the monitor. How often this is needed depends on the site. Some sessions last days, some last weeks. Sites with tight security settings expire sessions after a shorter period.
Custom request headers
Some services use a different form of authentication: a Bearer token in the Authorization header, or a custom API key header. This is common with internal tools, dashboards built on top of APIs, or pages that use token-based auth rather than cookies.
For these, the Custom Request Headers field accepts any header you need in Name: Value format, one per line:
Authorization: Bearer your-token-here
X-API-Key: abc123
These headers are sent alongside every check, the same as the cookie.
What you can watch with this
The obvious use case is competitor intelligence. Some companies keep their detailed pricing, feature comparisons, or customer-facing documentation behind a login. If you have a legitimate account, you can monitor those pages the same way you would a public pricing page.
Beyond that, authenticated monitoring is useful for:
- Internal dashboards where you want to catch unexpected changes
- Supplier portals that publish pricing or availability behind authentication
- SaaS products you are subscribed to, where you want to know when something in the product or documentation changes
- Any page that has shifted from public to requiring a login over time
Setting up
When creating or editing a monitor, expand the Authentication section. Add your session cookie, any custom headers, or both. Everything else works the same way as a standard monitor: set an interval, optionally scope it to a specific part of the page with a CSS selector, and add keyword alerts if you only care about specific words appearing or disappearing.
The first check establishes a baseline. From then on, any change to the page content triggers an alert.