TL;DR: Run a handful of scripted journeys along revenue paths (login, search-to-cart, pay) from user-representative regions on a steady cadence with retry-before-page, assert outcomes rather than DOM pixels, and investigate disagreements between canaries and dashboards, including probe defects.
How to approach it
Start by naming the money paths and the regional mix of real users; cadence and tool choice follow from those. Mentioning geography early matters, because most synthetic failures are regional and most synthetic setups are not.
A strong answer
Layer the checks by purpose. Shallow API availability pings every 30 to 60 seconds from multiple vantages catch process death cheaply. Deep scripted browser journeys (Playwright-style) every 5 to 15 minutes walk login, search-to-cart and payment confirmation. Use controlled test merchants/accounts and a documented reconciliation or void/refund path where a real payment is unavoidable; do not silently create customer charges. Certificate and DNS expiry probes run independently because both fail in ways metrics never see. In CI, the same journey suite hits staging as a smoke gate, and one canary runs against production immediately after rollout so regressions surface within minutes of the deploy rather than with the first angry customer.
Assert outcomes, not pixels. Expect a status code, a completed cart, a confirmation identifier; prefer asserting API payloads over brittle selectors, use stable test IDs where markup must be touched, and keep each journey under about a minute and ten assertions so maintenance stays survivable. A mega-journey clicking twenty pages breaks weekly, gets muted, and becomes worse than nothing because everyone stops trusting the signal.
Geography is the difference between green and truth. Run from the top user regions, not just the datacenter's backyard. For India-heavy traffic, probe from Indian networks: international transit hides last-mile ISP issues, CDN POP misconfiguration, and peering degradation that Mumbai or Chennai users experience as your outage. The scenario in the title is usually exactly this: a regional path broken, home-region probes healthy, internal RED metrics oblivious because the failure lived in DNS, CDN, TLS, or a third-party script, layers internal metrics cannot see at all.
False-positive discipline keeps pages credible. Page only after failure persists across consecutive runs, confirmed by an independent signal or vantage when possible; requiring two failing regions would suppress a real one-region outage; auto-rerun once before escalating. Publish canary results on the status page so support and engineering read the same truth during an incident instead of arguing about whose graph is right.
Synthetic and RUM are complements, not rivals. Synthetic proves known paths work under controlled conditions with a clean denominator, which suits availability SLIs and alerting. Real-user monitoring reveals paths people actually take, including the uninstrumented browser route behind the outage above; its denominator is messy but honest. Alert on synthetic, diagnose with RUM, and the unknown-unknown gap narrows from both directions.
Costs are worth actually computing, because the intuition about which checks are expensive is usually backwards. A browser journey every five minutes is 60 / 5 × 24 = 288 runs a day per region, so 288 × 30 × 3 = 25,920 executions a month across three regions. That is the check everyone worries about.
Now the cheap one. A shallow API ping every 30 seconds is 2 × 60 × 24 = 2,880 a day per vantage, and from five vantages that is 2,880 × 30 × 5 = 432,000 a month, roughly seventeen times the browser volume. Per execution it costs a fraction as much, but the multiplier is large enough that the ping budget frequently exceeds the journey budget, and it is the one nobody reviews because each check feels free. Price both against the provider contract before adding vantages, since the region count multiplies everything and is the parameter most often increased casually; script maintenance is another budget line, so every journey carries an owning team tag, runs against staging in CI so breakage lands in the PR that caused it, and mutes require an owner and expiry.
What interviewers probe next
"Login needs credentials inside the canary." Dedicated canary accounts with vaulted secrets, least privilege, rate-limit exemptions documented with the abuse team, rotated like any production credential.
"Journeys break on every deploy and teams muted them." That is selector brittleness plus missing CI integration; fix assertion targets and run journeys pre-merge, and muting without expiry should require the platform team, not just a checkbox.
"Synthetic or RUM for the SLI?" Both, published separately: synthetic gives deterministic conditions for the availability objective, RUM reports experienced reality; conflating them produces objectives nobody trusts.
Common mistakes
Probing only from the region hosting the datacenter and declaring global health from it.
Paging engineers off a single failed probe from one vantage, teaching the on-call to ignore the channel within a month.
Treating synthetic coverage as a substitute for RUM rather than the other half of the picture.