Login
Sites with customer accounts, B2B panels, SaaS
- 01Go to the login page
- 02Fill in the test account's login and password
- 03Click “Log in”
- 04Check text: the account name in the header
Browser scenarios
Browser scenario monitoring: the checkout flow checked the way a customer would
An HTTP check says the server responded. A browser scenario says a customer could log in, add a product to the cart and reach the payment step. Uptimo runs it in a real browser every few minutes, and when a step fails it leaves material you can sit down with and fix right away.
The difference
How a scenario differs from an HTTP check
You need both. An HTTP check catches a total outage in a few milliseconds and costs nothing. A scenario catches a process failure, the kind where the server answers 200 and the customer still cannot pay.
Aspect
HTTP check
Browser scenario
What it checks
Whether the address responds, and with which code
Whether the path can be completed: login, cart, form, payment
How
A single HTTP request
A real browser (Playwright) clicks, fills in, waits and reads text
Run time
2 to 19 ms (median from measurements)
about 2.7 s (median from measurements)
Result on failure
Response code and time
Step number, time of every step, video, screenshots, HAR
False “working”
An error page with code 200 passes
The “check text” step requires e.g. “Thank you for your order”
No code
How you build a scenario without writing code
A scenario is a list of steps picked from a list. Each step has its own time and its own result, so you see not only that the scenario failed, but where, and how much earlier it started to slow down.
01
Go to
Open an address: the login page, a product page, a form.
02
Fill in
Type a value into a field: login, password, postcode, e-mail address.
03
Click
A button, a link, an element pointed to by a selector.
04
Wait for an element
Until the cart, the summary or the payment gateway appears.
05
Check text
Confirm the page shows what it should, not a pretty error page.
Or describe it in your own words
You can also describe the path in plain sentences, one instruction per line: “Go to shop.com”, “Type ‘mug’ in the search box”, “Click the ‘Add to cart’ button”, “Check for the text ‘added to your cart’”. The builder opens your page, runs those steps live and shows the result of each one with a screenshot. A green row means “this just ran on your page”, not “this is roughly how it should look”. Sign-in details go in a separate field and never reach the AI model.
Failure evidence
What you get when a scenario fails
The material is created automatically and only on failure. It does not have to be switched on “just in case” and it does not fill the disk with scenarios that pass.
Video of the run
The whole run from the first step to the error: you see what the browser showed at the moment of failure.
A screenshot of every step
A separate image after each step, so comparing “before” and “after” does not require scrubbing through the video.
HAR with network requests
A list of requests with codes and timings. Saved without response bodies. Diagnostic material does not become a copy of your site's data.
Step number and second
The ticket for the team reads “step 4, payment, 03:12:41, the request to the gateway returned 502”, not “something is wrong with the cart”.
Examples
Typical scenarios
Cart and payment gateway
Online shops
- 01Go to a product page
- 02Click “Add to cart”
- 03Fill in delivery details
- 04Wait for the payment gateway
- 05Check text: the payment provider's name
Contact or lead form
Service companies, B2B, booking systems
- 01Go to the form page
- 02Fill in the fields marked as test
- 03Click “Send”
- 04Check text: the confirmation message
Search and product list
Shops and catalogues with their own search engine
- 01Go to the home page
- 02Fill in the search box
- 03Wait for the results list
- 04Check text: the name of a known product
Price
What it costs and why
A scenario occupies a browser processor for about 2.7 s, an HTTP check for a few milliseconds. That is why the pricing charges for the number of scenarios and the frequency, not for the number of users or lightweight checks.
Start1 scenariofrom 5 minutesPLN 149 / month net
Team10 scenariosscenario every 5 minutesPLN 399 / month net
Agency30 scenariosscenario every 5 minutesPLN 899 / month net
Add-ons: 5 extra scenarios PLN 79/month, interval shortened to 30 s PLN 129/month. Annual billing 20% off. The Solo plan (PLN 0) has no scenarios: it includes HTTP, DNS, ping, TCP and certificate checks.
Limitations we state openly
- Scenarios run from one location in the European Union. We do not pretend to run a network of a hundred probes. For a business process, frequency and scenario fidelity matter. Additional locations are part of a dedicated instance.
- Recordings, screenshots and HAR files are kept for 14 days. The incident history stays, because the SLA is calculated from it.
- A scenario does not bypass anti-bot protection or two-factor authentication. Monitoring uses a test account without 2FA, and a checkout scenario stops at the payment gateway or uses the provider's test mode.
- This is production monitoring, not a replacement for end-to-end tests in the release process. A scenario checks whether what is already deployed works for a customer at this hour.
Questions
What people ask before their first scenario
The scenario does exactly what the steps say. It usually ends at the payment gateway with a “check text” step (the provider's name), so no order is placed. If you want to check the payment itself, use the provider's test mode or a test account and a product priced at 0, and add a maintenance window for deployments so you do not get alarms when you switch the shop off yourself.
The scenario does not bypass them and should not. For monitoring you create a test account without two-factor authentication; if login always requires a CAPTCHA, monitor the steps before it (login page availability, the form) and separately the steps after login, if your site allows skipping the CAPTCHA for a designated account.
Every 5 minutes, in every plan. That is the floor for browser scenarios and it does not depend on what you pay: every run is a full pass in a real browser, so running it more often would not give you better monitoring and would crowd the queue shared with every other check. A shorter interval, from 1 minute (or from 30 seconds on a dedicated instance), applies to lightweight checks: the page, DNS, ping, a TCP port.
No. You pick the steps from a list (go to, fill in, click, wait, check text) and point at elements on the page. You can also describe the path in plain sentences; the builder runs them on your page and shows the result of every step before you save. The first checkout scenario then usually takes fifteen minutes rather than an hour.
You get the material (video, screenshots, HAR) and the incident goes into the history. Alert conditions are set separately: on failure, on recovery and on a problem that is still going on, so that a single stumble does not wake anyone at three in the morning, but the third one in a row does.
Build your first scenario this afternoon
Create an account, pick the path you make money on and leave the scenario for a day. If it finds nothing, you know it from a measurement, not from hope.