Skip to content

Synthetic Health Check

Software or tool — instantiates Correlated Proxy Monitoring

Runs artificial transactions or probes to infer whether a system path is functioning when direct user-impact observation is delayed.

Version
v1 · 2026-08-24 · History
Mechanism #
9069
Type
Software or Tool
Form family
Monitoring, Sensing & Alerting
Solution family
Measurement & Observability
Problem family
Observability, Measurement & Feedback Gaps
Problem subfamily
Hidden State, Structure & Trajectory Visibility
Origin domain
Computer Science & Software Engineering
Also from
Engineering & Design
Instantiates
Correlated Proxy Monitoring

Synthetic Health Check manufactures its own signal: instead of waiting for real users to reveal a problem, it runs a scripted, artificial transaction — a login, a search, a checkout, an API call — against the live system on a fixed cadence and reads the result as a proxy for whether that path works for everyone. Its distinguishing move is that the probe is active and independent of real traffic: it can detect a broken path at 3 a.m. with zero users online, before anyone is harmed. The price of that independence is a sharp blind spot — the probe only ever exercises the scripted path — so an honest synthetic check must annotate exactly what its green light does and does not cover.

Example

A bank needs to know its mobile app's login works, but real login-failure data arrives only after frustrated customers give up — and at 4 a.m. there may be no customers to reveal an outage at all. So it deploys a synthetic health check: from probe agents in three regions, every 60 seconds a robot performs a full scripted login against production with a test account and records success, latency, and the failing step. A run that fails in Frankfurt but passes in Virginia localizes a regional outage; three consecutive failures anywhere pages the on-call team — often before the first real customer notices. The probe's dashboard is careful to annotate its scope: "verifies scripted login only; does not exercise biometric login, password reset, or post-login transfers." When a bug broke password reset while login stayed green, that annotation is what stopped anyone from reading the green check as "auth is fine."

How it works

  • Script a representative user journey and run it as an artificial transaction on a fixed cadence, independent of real traffic.
  • Validate that the scripted path genuinely represents the real user journey it stands for — otherwise the probe is green about a path nobody uses.
  • Fire a response rule on consecutive probe failures (single failures are often transient), capturing location and step for triage.
  • Annotate the probe's coverage explicitly, so a passing check is read as "this scripted path works," never "the system is healthy."

Tuning parameters

  • Probe frequency — how often the transaction runs; more frequent shrinks detection time but adds synthetic load and cost.
  • Script scope — how much of the real journey the probe exercises; broader scope shrinks the blind spot but is costlier and more brittle to maintain.
  • Vantage spread — how many independent probe locations; more vantages localize faults but multiply infrastructure.
  • Failure-confirmation count — how many consecutive failures before alerting; higher suppresses transient blips but delays real detection.
  • Coverage-annotation granularity — how explicitly the untested paths are enumerated; finer annotation prevents over-reading at the cost of upkeep.

When it helps, and when it misleads

Its strength is constant, traffic-independent assurance that critical paths work, with lead time on real-user harm, even when nobody is watching. It pairs naturally with passive telemetry: synthetic tells you a path can work, telemetry tells you what real users are experiencing.[n1] Its failure mode is over-reading a narrow green: the probe validates one scripted path and is blind by construction to everything it does not script, so a passing check can coexist with widespread breakage — false reassurance in its purest form. The classic misuse is treating "all synthetics green" as "system healthy" and cutting real-user monitoring. The guarding discipline is honest coverage annotation and validating that the scripted path still mirrors the real journey.

How it implements the components

  • proxy_signal — the scripted synthetic transaction's result is the observable stand-in for real path health.
  • correlation_validation — the probe is checked to genuinely represent the real user journey it proxies, not a divergent test path.
  • response_rule — consecutive-failure logic converts probe results into a located, staged alert.
  • uncertainty_annotation — explicit coverage scope marks what the green light does and does not attest, guarding against over-reading.

It does not triangulate multiple live signals or keep a physical calibration schedule — Telemetry Proxy Monitoring and Remote Sensor Proxy Network do — and it defines no lagging target outcome the way Leading Indicator Dashboard does.

Editorial Notes

Form Classification

Form family: Monitoring, Sensing & Alerting

Rationale: Synthetic Health Check operates as ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response because it runs artificial transactions or probes to infer whether a system path is functioning when direct user-impact observation is delayed.

Independent corroboration: The frozen evidence defines Synthetic Health Check as 'Runs artificial transactions or probes to infer whether a system path is functioning when direct user-impact observation is delayed', so its operative form is Monitoring, Sensing & Alerting.

Nearest alternative: Experiment, Test & Rehearsal — Synthetic Health Check includes features of an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation, but its defining operation is ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response.

Review outcome: Independent reviewer agreement; medium confidence.

Origin Attribution

Primary origin: Computer Science & Software Engineering

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Universal

Rationale: Artificial transactions that continuously test a service are standard software observability probes.

Related originating lineages:

Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined evidence shows material contributions from several lineages. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; high confidence.

Notes

[n1] Synthetic monitoring (scripted probes) and real user monitoring (RUM) are complementary: synthetic checks confirm a path can work on a fixed cadence independent of traffic, while RUM reports what actual users experience. Each covers the other's blind spot, which is why mature setups run both rather than choosing one.