Guide
Synthetic monitoring: know a journey broke before your users tell you
Synthetic monitoring runs scripted journeys against your live system on a schedule, as a user would, and alerts you when one fails or gets slow. It complements uptime checks and logs by testing the tasks that matter.
What synthetic monitoring is
An uptime check asks whether a URL answers. Real-user monitoring measures what actual visitors experience. Synthetic monitoring sits in between: a scripted user signs in and does a task, every few minutes, and the result is recorded and alerted on.
Because the script runs whether or not anyone is using the product, it finds problems at night and on quiet days, and because it does a real task, it finds the problems an uptime check can’t: a sign-in that fails for one identity provider, a create that answers 500, a list that takes eight seconds.
What to monitor
- Sign-in per role and per sign-in method. If people can’t sign in, nothing else matters.
- The core task. The one thing your customers pay for: placing an order, submitting a claim, running a report.
- Read-only on production. Monitors that create data on production need clean-up and care; most monitors only read.
- Dependencies through your API. A journey that reaches the payment provider or the search index through your API tells you when those break, as your users see it.
Intervals and alerts
- Choose the interval by how fast you need to know: every minute for sign-in and the core task, less often for the rest.
- Alert after more than one failure in a row, so a single network hiccup doesn’t wake anyone, and send one alert when it recovers.
- Send alerts where the team already looks (chat or email), with the failing step and its answer in the message.
- Track pass rate and timings over time, so a slow decline is visible before it becomes a failure.
What synthetic monitoring doesn’t tell you
A monitor runs from where it’s installed, as the accounts you gave it. It doesn’t show what users on another continent experience, or what happens on the screens; for that you need real-user monitoring and browser tests. It also only covers the journeys you scripted, so keep the list in step with what your customers actually do.
Synthetic monitoring in Journey Lanes
Any flow in Journey Lanes can be monitored: choose an interval in the top bar, and the flow runs against the environment it was switched on for, with pass rate and p50/p95 timings per flow. When a flow has failed a number of monitor runs in a row (two by default, one to five), every alert channel gets one alert naming the failing step; one more goes out when it passes again. Channels are email (confirmed addresses), Microsoft Teams, Slack and webhooks (monitoring and alerts).
An employee logs in. The employee sees the products and orders a product. The employee sees their orders.
- Employee
POST /realms/portal/protocol/openid-connect/token200 - Employee
GET /api/products200 - Employee
POST /api/orders201 - Employee
GET /api/orders200
Monitors run from the Journey Lanes server. The shortest interval depends on the plan (pricing); writes stay off on an environment until you allow them, and clean-up steps remove what a run created.
Questions
What is the difference between synthetic monitoring and uptime monitoring?
Uptime monitoring checks that an address answers. Synthetic monitoring runs a scripted task, such as signing in and placing an order, and checks every step of it.
How often should synthetic monitors run?
Often enough to learn about a failure before your users report it: every minute to every few minutes for sign-in and the core task, less often for less critical journeys.
Do synthetic monitors create load on production?
Very little: one user doing one task at the chosen interval. Keep production monitors read-only unless they clean up after themselves.
Monitor the journeys that matter
Switch on monitoring for a flow and add an alert channel; you hear once when it fails and once when it recovers.