Check whether the important journey succeeds
Your website returns HTTP 200, yet customers cannot sign in. A form loads, but its submit button no longer reaches the expected page. These failures show why application availability needs more than a successful response from the homepage.
Browser monitoring runs a deliberately configured sequence of interactions and checks its outcome. With MetriBeacon, you can observe a selected login or form journey, inspect individual steps and connect useful alarms. Start with one important flow so that a failed result tells you what needs investigation.
Browser monitoring and HTTP checks answer different questions
An HTTP monitor checks the request and response you configure. It is useful for availability, response times, certificates and supported content conditions. Read the website monitoring guide and API monitoring article when choosing those checks.
A browser check can open a page, fill fields, click a control and verify the expected visible result. That can reveal a broken interaction even when the server still returns a successful response.
| Observation | What it supports | What it does not establish |
|---|---|---|
| A successful HTTP response | The configured request met its response conditions | Every customer interaction works |
| A successful browser journey | The selected steps and expected result succeeded in that run | Every account, device and workflow works |
| No current browser result | The flow lacks a fresh observation | A confirmed failure or a healthy application |
This is synthetic monitoring: an automated scenario you define. It complements application and server observations. It is not a measurement of every real visitor's experience, and a step duration is not automatically a full browser performance score.
Choose one small, repeatable scenario
Pick a journey whose failure matters. A useful first login check might open your sign-in page, enter a dedicated test account, submit the form and confirm a recognisable heading on the account page.
Those are example steps, not a scenario already connected to your application. Your own selectors, permitted target and expected result must match your website. For a form check, choose a controlled test environment or a route designed for repeatable test submissions. Avoid a scenario that purchases products, contacts real customers or changes production records each time it runs.
Keep the successful end explicit. Merely clicking “Sign in” does not prove that sign-in succeeded. Merely loading the form does not prove that submission worked. Select an outcome that would distinguish a completed operation from its initial screen.
Keep separate goals in separate scenarios. A long journey that mixes sign-in, uploads and administration can be harder to interpret than a short check for each important outcome.
Create the browser monitor in MetriBeacon
Follow the browser-check setup guide. You need permission to edit the workspace and an approved public target.
- Choose Add monitor → Websites & applications → Browser check.
- Give the monitor a recognisable name and enter its starting URL.
- Choose the supported checking locations and browser engines offered in the form.
- Set the interval and inspect the estimated usage.
- Add a short sequence with an explicit expected result.
- Review the configuration, save and inspect its first result.
Choose only the engines and locations you can actually select; do not assume every browser or geographic region is available. Central checks use permitted public targets. Use the capabilities offered in your setup rather than treating private-network access as a default feature.
The browser monitoring overview explains the relationship between configured steps, results and incidents. The usage and quota overview helps you plan runtime and frequency within account budgets.
Make selectors and assertions meaningful
A selector tells the check which element to interact with or inspect. Choose one that identifies the intended field, button or result consistently. Verify that it matches the correct element after a page update, not simply the first similar control on the screen.
Use the supported result checks to describe success, such as expected text in a selected heading or the expected destination URL. A generic assertion that some page appeared may pass even when the application displays an error page.
For the illustrative login journey, check a heading that is specific to the signed-in view. Do not assert a visitor's personal name when a stable, non-sensitive marker can express the same successful outcome. The test should tolerate harmless wording or layout changes only where those changes do not alter its meaning.
Inspect the first run before relying on a schedule. Confirm the selectors target the intended controls, the expected outcome really distinguishes success and the recorded timings describe the step you meant to measure.
Keep account credentials and recordings deliberate
Use a dedicated test account with only the permissions the scenario needs. Keep production customer sessions and personal accounts out of the check. Choose the protected-value fields for credentials instead of pasting passwords into ordinary step text, names or examples.
MetriBeacon stores secret values through separate, target-bound configuration. Review the permitted target when changing the start URL or the journey. A configured browser check does not promise a way around CAPTCHA, multi-factor authentication or your application's access rules; plan a legitimate test flow your application can support.
Screenshots and traces begin disabled. Enable optional recording only after reviewing and explicitly approving the content that could be captured. A screenshot can contain account data, and a trace can contain sensitive interaction details. Do not assume that ordinary test text is automatically harmless.
Recordings have limited retention. Treat them as optional diagnostic evidence for the recorded run, rather than a permanent incident archive. Begin without them when step results already answer your first investigation question.
Read failures in their checking context
Open the monitor and identify the failed step. If navigation succeeded but the expected heading was missing, inspect the assertion, page content and the application's state. If the intended button cannot be found, review its selector and any recent interface change.
A failed scenario is evidence about that configured journey. It may represent an application problem or a check that no longer matches the page. Investigate the result instead of automatically assigning every failure to the whole service.
Missing observations, unavailable checking capacity, paused execution and account-budget constraints are different from a confirmed failed interaction. Wait for a fresh valid result before declaring recovery. The heartbeat and freshness guide explains why an older successful observation cannot establish the current state.
Compare timestamps with your server observations, deployment changes and HTTP monitor. These signals help narrow the investigation; coincidence alone does not establish the cause.
Add an alarm with a useful response
Review the alarm suggestions and enable the conditions you actually want to monitor. Choose an appropriate recovery condition and a confirmed notification destination. Follow the alarm setup guide and email and Telegram article to test delivery.
Decide who receives the alert and what they should inspect first. For a login scenario, that might be the failed step, a changed selector, the identity service or a recent application deployment. An alert is more useful when it starts a concrete investigation.
Test a controlled failure in your own non-production flow, then restore it and confirm a fresh successful result. When customers need an explanation, publish reviewed information through a status page. Internal credentials and test-account details do not belong in that public message.
Frequently asked questions about browser monitoring
Can a browser check detect a broken login when HTTP monitoring is green?
Yes, when the configured scenario exercises the login and explicitly checks its successful outcome. The HTTP monitor and browser scenario observe different parts of the service.
Does one successful run prove that every user can sign in?
No. It establishes success for the selected journey, test account, offered engine and checking location in that run. Add relevant scenarios deliberately rather than claiming coverage you have not configured.
Are screenshots or traces saved automatically?
No. They start disabled and require explicit approval of the content to be recorded. Check retention and the information your chosen account can expose before enabling them.
Is browser monitoring free with MetriBeacon?
MetriBeacon is free within its documented technical quotas. Review the usage estimate, available checking capacity and selected interval before increasing the number of scenarios or engine combinations.
Start with one important interaction
Create a free MetriBeacon account, choose a browser check and begin with one short, repeatable journey. Confirm its first result, protect the test account's credentials and test a useful alarm. The Website/API template below opens a complementary HTTP monitor; create the browser scenario through the separate browser-check entry.
