Website monitoring for online shops and portals: uptime checks, synthetic transactions and real user monitoring
What uptime checks, multi-step synthetic transactions and real user monitoring each detect, how often to run them, how to avoid false alarms and what 99.9% uptime really means in minutes.
Summary
- Website monitoring for a shop or portal needs three layers: simple uptime checks for availability, multi-step synthetic transactions for critical journeys such as login and checkout, and real user monitoring for what customers actually experience.
- Certificate and domain expiry, DNS, third-party scripts and payment providers cause many outages that a plain HTTP check never sees, so they deserve their own checks.
- Confirm failures from several locations before alerting, communicate through a status page and translate uptime targets into minutes: 99.9% allows roughly 43.8 minutes of downtime per month.
Website monitoring tells you whether your online shop or customer portal is reachable, fast and working before your customers tell you otherwise. For a business that earns money through a browser, "the website is up" is not a single fact: the home page can return HTTP 200 while the login fails, the search returns nothing or the payment step times out because a third-party provider is degraded.
This guide explains the three layers of website monitoring that matter for shops and portals: uptime checks, multi-step synthetic transactions and real user monitoring. It covers check locations and frequency, SSL/TLS certificates, domains and DNS, performance budgets and Core Web Vitals, third-party scripts, false alarm prevention, status pages and what uptime percentages mean in minutes. At the end you will find a table of check types and a checklist you can copy.
Three layers: uptime checks, synthetic transactions and real user monitoring
Each layer answers a different question, and none replaces the others.
Uptime and HTTP checks
An uptime check sends a request to a URL from an external location and evaluates the response: status code, response time, optionally a keyword in the body or a header. It is the classic form of black-box monitoring: it knows nothing about your internals, but it sees what the outside world sees. Uptime monitoring is cheap, runs every minute and is the foundation for measuring uptime. Its limit: it checks a single request. A page that loads but shows an error message, or a checkout that breaks after the second step, passes.
Make HTTP checks more useful by asserting on content (for example, the text "Add to cart") and by monitoring a health endpoint that checks dependencies such as database, search and cache.
Multi-step synthetic transactions
Synthetic monitoring runs scripted user journeys in a real browser: open the start page, search for a product, put it in the cart, log in, start the checkout up to the payment step. Each step has assertions and timings. This is how you detect broken JavaScript, failed API calls behind the UI, expired session handling or a search index that returns empty results. For a shop, the journeys that earn money are the ones to script first. Obseria's synthetic monitoring runs such browser and API checks from several regions.
Practical rules for synthetic journeys: use dedicated test accounts and test products, stop before a real payment is charged (or use the provider's sandbox), tag synthetic traffic so it is excluded from analytics and conversion reporting, and keep scripts in version control so they change together with the site.
Real user monitoring
Real user monitoring (RUM) collects timings and errors from the browsers of actual visitors. It shows what synthetic checks cannot: performance on slow mobile networks, specific browsers or devices that break, regional problems and the long tail of pages nobody scripted. RUM needs traffic, so it is weak at night and on low-traffic pages, which is exactly where synthetic checks help. Together, both layers form what is often called digital experience monitoring.
Check types, what they detect and how often to run them
The table below is a starting point for a typical online shop or portal. The frequencies are examples; adjust them to your traffic, revenue per minute and the cost of the checks.
| Check type | What it detects | Recommended frequency (example) |
|---|---|---|
| HTTP/HTTPS uptime check (home page, key landing pages) | Outages, 5xx errors, timeouts, slow responses, wrong redirects | Every 1 minute from 3+ locations |
| Keyword or content assertion | Error pages returning 200, empty templates, maintenance pages left on | Every 1–5 minutes |
| API / health endpoint check | Failing backend dependencies (database, search, cache, auth) | Every 1 minute |
| Multi-step synthetic: login | Broken authentication, SSO or session handling | Every 5 minutes |
| Multi-step synthetic: search and product page | Empty search results, broken product data, JavaScript errors | Every 5–10 minutes |
| Multi-step synthetic: cart and checkout up to payment | Broken checkout, payment provider redirect failures, shipping or tax calculation errors | Every 5 minutes |
| SSL/TLS certificate check | Expiring or invalid certificates, incomplete chains, hostname mismatch | Daily; alert 30, 14 and 7 days before expiry |
| Domain expiry check | Domains about to lapse at the registrar | Daily; alert 60 and 30 days before expiry |
| DNS check | Wrong or missing records, unexpected changes, resolver failures | Every 5 minutes |
| Heartbeat for scheduled jobs (feeds, exports, sitemaps) | Jobs that silently stopped running | Expected interval of the job plus grace period |
| Real user monitoring | Core Web Vitals, JavaScript errors, slow regions, devices and browsers | Continuous (all or sampled sessions) |
The heartbeat row is easy to forget. Product feeds for marketplaces, price exports and nightly imports do not have a URL to check, so they report in instead; this pattern is described in our glossary entry on heartbeat monitoring.
Check locations and frequency
Run checks from where your customers are. A shop that sells in Germany, Austria and Switzerland needs at least two or three locations in Central Europe; if you also sell to the UK or the US, add locations there. Checks from a single data center will report the network problems of that data center as your outage.
Frequency is a trade-off between detection time and cost or noise. With a 1-minute interval and confirmation from a second location, you typically know about a hard outage within two to three minutes. With a 15-minute interval, an outage can go unnoticed for a quarter of an hour, which for a busy shop is a measurable loss. Browser-based synthetic journeys are more expensive than HTTP checks, so a common pattern is: HTTP checks every minute, critical journeys every five minutes, secondary journeys every 15 to 30 minutes.
Also monitor the response time, not just availability. Measure time to first byte (TTFB) and total time per step, and alert on sustained degradation, not on a single slow sample.
SSL/TLS certificates, domain expiry and DNS
An expired certificate makes browsers show a full-page warning; for most visitors, that is the same as a site being down. Automated renewal reduces the risk but does not remove it: renewals still fail because of DNS, firewall or rate-limit problems.
- Certificates: check every public hostname, including API, CDN, image and payment callback domains. Verify expiry date, chain completeness and hostname match. Alert well in advance and again shortly before expiry.
- Domains: monitor registration expiry for your main domain and for every domain used in emails, redirects and campaign landing pages. Make sure the registrar account has a valid payment method and an owner who still works for the company.
- DNS: check that A/AAAA, CNAME and MX records resolve to the expected values from several resolvers, and alert on unexpected changes. A wrong DNS change can take a site offline for hours because of caching, so detection speed matters.
Performance budgets and Core Web Vitals
A slow shop is a partially broken shop. Performance budgets turn "fast enough" into numbers you can monitor, for example a maximum page weight, a maximum number of third-party requests or a maximum TTFB for product pages. Google's Core Web Vitals provide the user-centric part of such a budget. According to web.dev, the thresholds are evaluated at the 75th percentile of page loads, separately for mobile and desktop:
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the largest visible element has rendered | ≤ 2.5 s | > 4 s |
| Interaction to Next Paint (INP) | Responsiveness to clicks, taps and key presses | ≤ 200 ms | > 500 ms |
| Cumulative Layout Shift (CLS) | Visual stability: unexpected layout shifts | ≤ 0.1 | > 0.25 |
Values in between count as "needs improvement". Synthetic lab measurements catch regressions after a deployment, but Google evaluates field data from real users. Track both, and break RUM data down by page type (home, category, product, cart, checkout) because their performance profiles differ.
Third-party scripts and payment providers
A typical shop page loads tag managers, analytics, consent banners, chat widgets, review widgets, A/B testing tools and recommendation engines. Each can slow rendering or throw errors, and you do not control their deployments. Payment providers, address validation and shipping APIs are even more critical: if they are down, your checkout is down, even though your own servers are healthy.
- Inventory all third-party domains your pages load and assign an owner for each.
- Use RUM to measure the impact of third-party scripts on LCP and INP and on JavaScript error rates.
- Include the redirect or embedded form of the payment provider in the checkout journey, using sandbox credentials where available.
- Monitor the status pages or status APIs of critical providers, and correlate their incidents with your own checks.
- Load non-essential scripts asynchronously and define what happens when they fail, so a broken chat widget cannot block the checkout button.
Avoiding false alarms
Most false alarms in website monitoring come from network blips, single-location problems and overly strict timeouts.
- Confirm from multiple locations: alert only when, for example, at least two of three locations see the failure. One failing location is more likely a network problem at that location.
- Retry before alerting: rerun a failed check immediately once or twice; alert on consecutive failures, not a single one.
- Realistic timeouts and thresholds: base response time thresholds on observed percentiles, not on wishful numbers.
- Maintenance windows: pause or annotate checks during planned deployments and maintenance.
- Route by severity: a checkout failure pages the on-call engineer; a slow blog page creates a ticket.
- Connect to telemetry: link synthetic failures to backend traces and logs so the responder sees the cause, not only the symptom.
What uptime percentages mean in minutes
Uptime targets in contracts and SLAs sound similar but differ a lot in practice. The table assumes an average month of 30.4 days (365 days divided by 12, which equals 43,776 minutes) and a year of 365 days (525,600 minutes):
| Uptime | Allowed downtime per month | Allowed downtime per year |
|---|---|---|
| 99% | ≈ 437.8 min (about 7 h 18 min) | ≈ 87.6 h (about 3.65 days) |
| 99.5% | ≈ 218.9 min (about 3 h 39 min) | ≈ 43.8 h |
| 99.9% | ≈ 43.8 min | ≈ 8 h 46 min |
| 99.95% | ≈ 21.9 min | ≈ 4 h 23 min |
| 99.99% | ≈ 4.4 min | ≈ 52.6 min |
Two details matter when you report against these numbers. First, define what counts as down: only total unavailability, or also a broken checkout or a response time above a threshold? Second, define how it is measured: the share of failed check intervals, confirmed from how many locations. With 1-minute checks, a target of 99.99% leaves room for only about four failed intervals per month, so the measurement method decides whether you meet the target.
Status pages and communication
When something breaks, customers and support teams want to know three things: is it known, what is affected and when is the next update. A status page answers these questions in one place and reduces support tickets during an incident. List components the way customers think about them (shop, checkout, customer account, API), post the first update within minutes, update at fixed intervals even if nothing has changed, and publish a short summary afterwards. Host the status page independently of your main infrastructure so it stays reachable when the shop is not.
Website monitoring checklist for shops
Copy this checklist into your wiki or ticket system and work through it:
WEBSITE MONITORING CHECKLIST FOR SHOPS
[ ] HTTP checks every 1 min for home, category, product and checkout URLs
[ ] Content assertions (keyword) on key pages, not only status codes
[ ] Health endpoint that checks database, search, cache and auth
[ ] Synthetic journeys: login, search, product page, cart, checkout to payment
[ ] Synthetic traffic tagged and excluded from analytics
[ ] Check locations in every main sales region (min. 3)
[ ] Alert only after retry + confirmation from 2 of 3 locations
[ ] TLS certificate checks for all public hostnames (30/14/7 days)
[ ] Domain expiry checks for all domains (60/30 days)
[ ] DNS record checks and alerts on unexpected changes
[ ] Heartbeats for feeds, exports, imports and sitemap jobs
[ ] RUM with Core Web Vitals per page type (LCP, INP, CLS at p75)
[ ] Performance budget defined and checked after each deployment
[ ] Inventory of third-party scripts with owners
[ ] Payment and shipping provider status monitored
[ ] Severity-based alert routing and maintenance windows
[ ] Uptime definition and measurement method documented for SLA
[ ] Status page hosted independently, update cadence agreed
How Obseria helps
Obseria combines external website monitoring with the telemetry from your backend, so a failed check leads directly to the traces, logs and topology behind it. Synthetic checks, real user monitoring and status pages run on the same OpenTelemetry-native platform as your metrics, logs and traces, with EU data residency and usage-based pricing.
- Browser and API synthetic checks from multiple regions with retries and multi-location confirmation.
- Real user monitoring with Core Web Vitals and JavaScript errors per page type.
- Status pages and incident management connected to the same alerts.
- Obseria Intelligence links a failing checkout to the backend service, deployment or third-party dependency that caused it.
You can set up your first checks for your shop in a free trial.