DOCUMENTATION / COMPONENTS

Components: HTTP checks & browser journeys

A monitor is the service or application you are watching. A component is one part of it that is checked on its own: a homepage, a dashboard, an API, a payment flow. Each component has its own type, schedule, timeout, status, performance history and alert settings.

Existing monitors

Every monitor you already had now contains a single Homepage HTTP component with the same URL, history, uptime and status page. Nothing needs to be set up again. Open a monitor and use Add component to add more.

Component types

Type	What it does	Settings
HTTP	Requests a URL and checks the response, exactly like the original monitor check.	URL, expected status (default 200), optional keyword that must appear in the page, check interval, timeout
Browser	Runs a step-by-step journey in a real headless browser, so you can test signed-in areas and how long a page takes to become usable.	Journey steps, secrets, check interval (minimum 5 minutes), timeout (10 to 120 seconds)

You can add as many components of each type as you need. Components can be enabled or disabled at any time; disabled components are not checked and do not affect the monitor’s status.

How the overall status is worked out

The monitor’s status comes from its enabled components. If every enabled component is up, the monitor is up. If one or more is down, the monitor is down, and each alert names the component that failed, for example “Acme App Dashboard is Down”. Webhook notifications include the component too.

The monitor’s average response time is based on its HTTP components only, because browser journeys take longer by design. Browser timings are shown on each component’s own page.

Browser components

A browser component opens a fresh, isolated browser for each check, runs your steps in order and closes it again. A check fails if a required step cannot complete: the page can’t be reached, a selector never appears, a click fails, you are sent to the wrong URL or the overall timeout is exceeded. A slow page is not a failure unless it passes the timeout.

Step types

Step	Configuration	Example
Navigate	URL	https://app.example.com/login
Fill field	Selector and value	input[name="email"] with {{EMAIL}}
Click	Selector	button[type="submit"]
Wait for URL	URL pattern	**/app
Wait for element	Selector or text on screen, and timeout	[data-testid="today-schedule"] or the text Today’s schedule
Measure page	Optional URL, what to wait for (a selector or text on screen), timeout and a label	Open /app and time it until the schedule is visible

Steps are added, edited, removed and reordered in a simple builder. There is no scripting: only these step types exist, and a journey can have up to 30 steps.

Waiting for text on screen

Measure page and Wait for element can wait for either an element (a selector) or a piece of text. Choose Text on screen and enter the words to look for. The text matches part of what is shown, ignoring upper and lower case, and only counts when it is actually visible: text in a hidden element does not count until it appears. If it never shows up, the check fails with a message naming the text.

Response time and page performance for browser checks

Each browser check records how the page itself performed, separately from how long the monitor took to run. Server response time (TTFB), First Contentful Paint, Largest Contentful Paint, layout shift, blocking time, DOM ready, the load event, number of requests, transfer size, failed requests, HTTP errors, console errors and JavaScript errors are all captured and shown in separate panels, and each can be compared with a warning and critical threshold.

The response time on the graph is the Measure page step: how long the content you chose took to become visible, measured from the first byte of the server’s response, so redirects, DNS, connecting and the server’s own response time are not counted (they are shown separately). If the journey has no Measure page step it uses Largest Contentful Paint, then First Contentful Paint, then DOM ready. The time it took the monitor to run, including starting the browser and every step, is shown as Total check and is never used as the page speed. A component can stay “Up” while its graph shows it getting slower.

Secrets

Sign-in details belong to the component, not the monitor. Add secrets such as EMAIL and PASSWORD, then reference them in step values as {{EMAIL}} and {{PASSWORD}}. Secrets are encrypted at rest, masked in the interface, never shown again after saving, and kept out of results, logs and error messages. A component can only ever use its own secrets.

Saved login sessions

Tick Login step on the steps that sign in. After a successful login the browser session is saved, encrypted, against that component only. Later checks restore it and skip the login steps, going straight to the page you are timing. If the session stops working, for example because you were redirected to the login page, the whole journey runs again with a fresh login and the new session is saved.

Timeouts

A browser check that runs out of time (exceeds the component’s timeout) says the monitoring run was too slow, not that your site is down. It is never counted as an outage for the monitor: the monitor’s status, uptime, outage history, alerts and public status page are not affected. Instead the timeouts are counted against the component, and only after 3 in a row is the component flagged as Timed out. Any check that finishes, pass or fail, resets the count. A step that fails inside the time limit, such as an element that never appears, is still an ordinary failure.

Failure diagnostics

Every browser check keeps a step-by-step trace: what each step did, the page it ended on, the HTTP status, when it started and how long it took, and whether login steps were skipped because a saved session was used. When a check fails you also see the failed step, the selector, the error and a screenshot of the page. Screenshots mask password fields and any field filled from a secret, are only available to you when signed in, and are removed after 7 days.

An example browser test case

This journey checks that a customer can sign in and that their dashboard becomes usable. It runs every 5 minutes with a 30 second timeout and two secrets, EMAIL and PASSWORD.

On the first run all six steps execute and the session is saved. On later runs only step 6 runs, so the graph shows the time it takes the dashboard to load. The result looks like this:

Slow-response alerts

Each component has its own Alert when slow setting and a threshold in seconds. You are alerted when a check is slower than the threshold and the last hour’s average is above two thirds of it, so a single spike is ignored. Raise the threshold, or turn alerts off, where slowness is acceptable. Slow responses never mark a component down; only the timeout does.

Public status page

Components are private by default. Choose Show on the public status page for the ones your customers should see. Only the component name and its status are shown, and hidden components never affect what visitors see. A monitor with a single public component looks the same as before.

Duplicating a component

Use Duplicate component to copy a component’s type, settings, journey steps and secrets in one click. The copy opens in the editor so you can rename it and adjust the steps. It starts with no history and no saved login session, and is hidden from the public status page until you choose to show it.

Security

• Browser components can only visit public websites. Localhost, private network ranges and cloud metadata addresses are blocked, including when a public page redirects to one.
• Each check uses its own isolated browser; state is never shared between components or accounts.
• You cannot run your own JavaScript or commands. Journeys are built only from the step types above.
• Every browser check has a hard time limit, and the number of browsers running at once is capped so they cannot overload monitoring.

Start monitoring for free →