Browser Monitor vs HTTP Monitor: A Decision Tree
Plain answer: HTTP monitors check that a server returns a status code. Browser login monitors run the page in real Chromium, fill the form, and confirm the dashboard actually loads. If your product has a login, a checkout, or any JavaScript-rendered surface, HTTP alone will return 200 while users see a broken screen. If your site is static marketing HTML, HTTP is enough. Velprove and Checkly are the only vendors that include a real browser monitor on the free tier. Better Stack, Datadog, Pingdom, and UptimeRobot all gate it behind paid plans. The seven questions below decide which one you need.
What HTTP monitors actually see (and miss)
An HTTP monitor opens a TCP connection, sends a request, and reads the response code, the headers, and optionally a slice of the response body. That is the entire surface. Per the Uptrends knowledge base on basic webpage versus real browser checks, a basic HTTP check only retrieves the initial response. It never executes JavaScript, never fetches stylesheets, never loads the third-party scripts your page depends on, and never touches an iframe. The monitor sees what curl sees, not what a person sees.
That gap is where most modern outages live. A login page that depends on Auth0, Clerk, or Supabase can return HTTP 200 while the auth widget never finishes loading. A React dashboard can return 200 with an empty HTML shell while client-side hydration fails silently. A Stripe checkout can return 200 while the payment iframe times out against a third-party CDN. In each case the origin is healthy, the status code is healthy, and the user is staring at a broken screen.
HTTP monitors still earn their spot. They are cheap, they are fast, they catch every outage where the origin server is genuinely down, and they give you sub-minute breadth across dozens of pages at low cost. The point is not that HTTP is broken. The point is that HTTP checks one layer of a stack that has at least three. If your product lives in the upper layers, HTTP alone will let many client-side failures through, and most client-side failures translate directly into customers who cannot complete the action they came for.
What browser login monitors actually do
A browser login monitor runs your page inside a real headless Chromium instance. It loads the URL, waits for the JavaScript to execute, fills the username and password fields, clicks the submit button, and then asserts that the post-login surface actually rendered. If the dashboard text appears, the monitor reports up. If the page hangs, throws, or returns the user to the login screen, the monitor reports down with a screenshot of what it saw.
That shape catches a class of failure HTTP cannot reach. Hydration errors that leave a blank React tree. Third-party script outages that block render. Payment iframes that fail to mount. Login services that return 200 with an error JSON body the UI misreads. Sessions that authenticate but never reach the dashboard because a downstream API call returns 500.
Velprove specifically runs the page in headless Chromium from our 5 regions (NA, EU, UK, Asia, OCE), captures a screenshot when the monitor fails, and supports username plus password login flows. It does not capture Core Web Vitals or LCP. It does not run on real customer browsers. It does not record flows from a Chrome extension. It does not support OAuth or 2FA login paths. The scope is deliberate: assert that a known credentialed login still leads to a rendered dashboard, every few minutes, from multiple regions.
The decision tree (seven binary questions)
The cheapest way to decide is to walk seven binary questions in order. Each one is grounded in a real failure mode rather than a theoretical one. If you want a wider lens that compares vendors as well as monitor types, our decision framework comparing 15 uptime monitors covers the vendor side. The seven questions below cover the monitor-type side.
Does your product require a login or session? Yes means you need a browser login monitor. HTTP checks return 200 on a login page that fails when JavaScript-driven auth (Auth0, Clerk, Supabase, custom session middleware) breaks. The Xbox Live July 2024 sign-in outage and the Meta March 2024 login disruption both look like this from the outside.
Do you take payments via embedded checkout (Stripe.js, Shopify, PayPal Smart Buttons)? Yes means you need a browser login monitor. The Stripe.js library, the Shopify Buy Button, and PayPal Smart Buttons all load client-side. HTTP cannot detect a healthy 200 page where the payment iframe failed to render or a third-party script timed out before mount.
Is your site primarily JavaScript-rendered (React, Vue, Next hydrated, single-page app)? Yes means you need a browser monitor. HTTP fetches the HTML shell. If hydration fails, the page is blank to the user, and the response code is still 200. A keyword assertion against the shell text passes while the page is empty.
Do you depend on third-party scripts in the critical path (analytics that block render, A/B testing tools, an embedded support chat that gates conversion, OAuth widgets)? Yes means you need a browser monitor. The Cloudflare June 2024 and September 2024 incidents broke downstream services whose own origins returned healthy. A browser monitor sees the actual third-party render path; an HTTP monitor on your own origin sees nothing wrong.
Is the surface a static marketing site (Hugo, Jekyll, plain HTML, a Next.js statically-exported landing page)? Yes means HTTP is enough. There is no JavaScript-critical path and no login. An HTTP monitor with a content keyword assertion covers the failure modes that matter at low cost.
Is your product server-to-server APIs only, with no human browser user? Yes means a multi-step API monitor is the right tool, and a browser monitor adds no signal. There is no DOM to assert against. The right test is a chained API call that proves the auth response, the token reuse, and the expected response body shape.
Do you need to verify post-login behavior, meaning that the dashboard rendered correctly after authentication succeeded? Yes means you need a multi-step browser monitor that asserts on dashboard content, not just on the login response. This is meaningfully different from question one. Question one asks if you have a login at all. Question seven asks whether you need to detect a different failure: authentication succeeds (the JWT call returns 200), but the React dashboard fails to hydrate. The user lands on a blank page behind a successful login. That shape is one of the most common partial outages in modern SaaS, and it is invisible to both an HTTP check on the dashboard URL and a single-step browser check that stops at the login redirect.
The summary is short. Any "yes" on questions one through four or on question seven means a browser login monitor is on the shopping list. A "yes" on question five points to HTTP-only. A "yes" on question six points to multi-step API monitoring. Most production products land on multiple yes answers and need both an HTTP layer for breadth and a browser layer for depth, which is the topic of a later section.
Real outages where HTTP returned 200 but users couldn't log in
The failure mode is not theoretical. Two real incidents in 2024 prove it. On March 5, 2024, Meta's login services broke for hours. Per Variety's reporting on the Meta March 2024 outage, thousands of Facebook and Instagram users were logged out and unable to sign back in. The marketing pages and the public surface were largely reachable. The login flow itself was the failure. An HTTP monitor on facebook.com would have shown green throughout. A browser login monitor that drives a real login flow would have gone red within one cycle.
On July 2, 2024, Xbox Live sign-in broke across PC, console, and cloud. Users could load Xbox web pages but could not authenticate their accounts. The pattern was the same: surface healthy, auth flow broken, status codes returning normally on the public pages. See why uptime monitors miss real outages for the full pattern.
Third-party dependency failures show the same shape from a different angle. The Cloudflare June 20, 2024 incident post-mortem documents 114 minutes of elevated latency and error rates that broke downstream services whose own origin servers returned healthy all along. If your site loads a Cloudflare-hosted script in the critical render path and that script fails to load, your HTTP monitor on your own origin reports green while real users see a half-rendered page.
A second Cloudflare incident on September 17, 2024 produced the same downstream pattern. Sites that depended on Cloudflare-routed scripts in the critical render path saw user-visible failures while their own origin HTTP monitors stayed green.
The cost of those misses is documented. The ITIC 2024 Hourly Cost of Downtime Survey of more than 1,000 firms found that the average cost of a single hour of downtime exceeds $300,000 for over 90% of mid-size and large enterprises, and that 41% of large enterprises (over 1,000 employees) report hourly costs between $1 million and $5 million or more. The often-cited $5,600-per-minute figure originates from a 2014 Gartner number and is no longer a current anchor. The ITIC 2024 number is the one to quote in 2026.
Status pages do not close that gap reliably. Community data tracked by aggregators such as IsDown suggests vendor status pages can lag third-party detection by an hour or more on real incidents. A browser monitor running on your own login path, from your own account, every few minutes, is the only signal that responds to your reality rather than the vendor's communications cadence.
Pricing reality across the market
Browser monitoring is more expensive than HTTP monitoring. As of May 2026, vendors price browser monitors roughly 5 to 10 times higher than HTTP monitors because they consume real Chromium instances rather than single TCP connections. Where the market diverges sharply is whether browser monitoring is available at all on a free tier.
Velprove and Checkly are the only vendors that include a real browser monitor on the free plan as of May 2026. Velprove Free gives one browser login monitor at a 15-minute interval, with no credit card required. Checkly Hobby includes 1,500 browser runs per month against a metered model, also free. Better Stack, Datadog, Pingdom, and UptimeRobot all gate browser monitoring behind paid tiers. UptimeRobot does not offer real browser synthetic monitoring at any tier; it covers HTTP, keyword, and port checks only.
The Velprove plan ladder is straightforward. Free at $0 includes 10 monitors, 5-minute HTTP intervals, 1 browser login monitor at 15-minute cadence, 3-step API monitors, email alerts, and 5 regions. Starter at $19 per month moves to 25 monitors, 1-minute HTTP intervals, 3 browser login monitors at 10-minute cadence, 5-step API monitors, and adds Slack, Discord, Teams, and webhook alerts. Pro at $49 per month moves to 100 monitors, 30-second intervals, 10 browser login monitors at 5-minute cadence, 10-step API monitors, and adds PagerDuty.
Other vendors land in different places. Better Stack's lowest tier with browser monitoring starts around $29 per month with a 5-monitor cap, which is why our Velprove vs Better Stack comparison flags the paid-only browser tier as the central swap reason for cost-sensitive teams. Checkly Starter at $24 per month increases the browser run quota to 3,000 per month with $6.50 per 1,000 in overage; the cost question between Checkly and Velprove comes down to whether a metered run-quota or a flat monitor-with-cadence model fits your workload, which our Velprove vs Checkly comparison breaks down concretely. Datadog Synthetic Monitoring runs roughly $12 per 1,000 browser test runs on annual commit and $15 to $18 on monthly. Pingdom starts around $10 per month for one advanced synthetic check.
The pricing reality matters because the right monitor type can flip the right vendor. A team that needs one browser login monitor for a SaaS sign-in pays $0 with Velprove, $0 with Checkly (if 1,500 runs per month is enough), and $29 or more anywhere else. The seven questions above decide if you need a browser monitor at all. Once you do, the free-tier shortlist is two vendors long.
When you need both (and how to combine them)
Most production sites need both layers. HTTP monitoring gives you breadth across many URLs at high frequency and low cost. Browser monitoring gives you depth on the surfaces that matter most. The two are complements, not substitutes.
A practical setup for a typical SaaS looks like this. HTTP monitors at 1-minute cadence on roughly 20 critical pages, including the marketing homepage, the pricing page, the docs landing page, the login page itself (just to detect a hard origin outage), the public API base URL, and any high-traffic blog posts. Plus one browser login monitor that drives the actual login flow and asserts the dashboard rendered. Plus one multi-step API monitoring flow that proves the auth-token-call-response chain for any customer integration that depends on your API.
The same logic applies to specific platforms. For SaaS-shaped products, our guide on how to monitor a SaaS login page walks through credential storage, region selection, and the dashboard-render assertion. For WordPress, our guide on how to monitor a WordPress login walks through the wp-login.php and wp-admin assertion path with a dedicated low-privilege test account, and the broader WordPress uptime monitoring guide covers the full WordPress monitoring stack from solo blog through WooCommerce to agency.
The right ratio is roughly 10 to 20 HTTP monitors for every 1 browser login monitor on a typical SaaS. The HTTP monitors give you fast detection of origin outages. The browser monitor gives you the truth about whether the customer-facing flow actually works.
Frequently Asked Questions
What is the difference between HTTP and synthetic monitoring?
HTTP monitoring fetches a URL and checks the response code, headers, and optionally a content keyword. Synthetic browser monitoring runs the page in real headless Chromium, executes JavaScript, fills login forms, and asserts that post-login content actually rendered. HTTP catches origin outages. Browser monitors catch JavaScript bundle errors, third-party script failures, hydration issues, and payment iframes that fail to load. Velprove offers both.
Do I need synthetic monitoring if I already have HTTP checks?
HTTP checks alone are not enough if you have a sign-in flow, an embedded Stripe checkout, a JavaScript-rendered dashboard, or critical third-party scripts. HTTP cannot see those client-side failures. HTTP is enough only if your site is static HTML or a server-rendered marketing page with no login or checkout. Real outages at Xbox Live (July 2024) and Meta (March 2024) broke login flows while origin servers stayed healthy. Add one browser login monitor for the critical flow.
Is API monitoring enough?
For server-to-server APIs with no human user, yes. Multi-step API monitoring asserts the auth call returns a token, the next call uses that token, and the response body matches an expected shape. Velprove supports 3-step API monitoring on Free, 5 on Starter, 10 on Pro. If a human ever logs into a UI built on top of those APIs, you also need a browser monitor. The login can succeed at the API layer while the dashboard fails to render.
Why do vendor status pages show green during outages?
Vendor status pages are updated by humans on the vendor's incident-response team. Third-party monitoring detects outages within minutes. Community data tracked by aggregators like IsDown suggests vendor status pages can lag third-party detection by an hour or more. The Cloudflare June 20 and September 17 2024 incidents are documented examples. This is why a browser monitor running from your own account, on your own login, is more reliable than a status page subscription.
How much does browser monitoring cost?
Velprove and Checkly are the only vendors that include a real browser monitor on the free tier as of May 2026. Velprove Free includes 1 browser login monitor at 15-minute intervals, no credit card required. Starter at $19 per month gives 3 browser monitors at 10-minute intervals. Pro at $49 per month gives 10 monitors at 5-minute intervals. Checkly Hobby is free with 1,500 browser runs per month. Better Stack starts at $29 per month. Datadog charges roughly $12 per 1,000 browser runs on annual commit. Pingdom and UptimeRobot do not include browser monitoring on free plans.
If your answer to any of questions one, two, three, four, or seven was yes, start a free Velprove account. The free plan includes 10 HTTP monitors across 5 global regions, 1 browser login monitor at a 15-minute interval, and multi-step API monitors up to 3 steps. No credit card required.