SRE Synthetic Monitoring

Real users report problems after they happen. Synthetic monitoring finds problems before users arrive. Small automated visitors test your service around the clock and raise an alert the moment something breaks.

What Is Synthetic Monitoring?

Synthetic monitoring runs scripted tests against a live service on a fixed schedule. Imagine a mystery shopper who walks into a store every five minutes, picks a product, pays at the counter, and reports any trouble. The shopper is a robot, and the store is your website or API.

Why Teams Use It

• Late-night problems get caught even when no real visitor is online.
• Tests from many cities show regional failures.
• Results stay consistent, so trends are easy to compare.
• Checks run against competitors or partner services to measure outside dependencies.

Types of Synthetic Checks

Health Checks

A health check calls a simple address, such as /health, and expects a fast success reply. Two common kinds exist:

• Liveness check: asks whether the program still runs.
• Readiness check: asks whether the program can serve traffic right now. A service that is still loading data answers no.

Uptime Checks

An uptime check requests a public page and confirms the status code, response time, and a keyword in the body.

Transaction Checks

A transaction check follows a full user journey, such as login, search, add to cart, and payment. It proves that the whole chain works, and not only the front door.

API Checks

An API check sends a request, validates the JSON answer, and measures response time.

How a Probe Works

 [Probe in Mumbai ]──┐
 [Probe in London ]──┼──→ [Your Service] → [Result Store] → [Alert Rule]
 [Probe in New York]─┘                                          ↓
                                                         [On-Call Phone]

Several probe locations separate a local network issue from a true outage. When one probe fails, the cause may lie in the path to that city. When all probes fail together, the service itself is down.

Example: Login Journey Check

1. Open the sign-in page and expect a result within 2 seconds.
2. Enter a test account name and password.
3. Click the sign-in button.
4. Confirm the dashboard page shows the text "Welcome".
5. Sign out and record total time.

A failure at step 3 points to the authentication service. A slow step 1 points to the web tier or the content network.

Synthetic Monitoring vs Real User Monitoring

Mature teams run both and compare the results.

Setting Good Checks

Frequency

Run critical checks every one to five minutes. Less important pages can run every 15 minutes.

Alert Rules

Require two or three failed runs before paging a person. A single failure often comes from a passing network glitch.

Test Accounts

Create dedicated test users and test products. Mark their orders so finance reports ignore them, and never use real customer data.

Common Mistakes

• Checking only the home page while checkout stays broken.
• Running probes from a single location.
• Letting test scripts rot after the interface changes.
• Paging on every single failure and training the team to ignore alerts.

Key Takeaways

Synthetic monitoring acts as a tireless tester that visits your service all day. Combine simple health checks with a few full-journey tests, run them from several regions, and connect results to clear alert rules.