Synthetic Monitoring Overview
Synthetic Monitoring opens a real browser on a schedule, walks through a website the way a customer would, and records whether each step worked and how fast the page was. Instead of waiting for a user to report that login is broken or checkout has slowed down, you find out first.
As someone responsible for a customer-facing website, I want CodeXray to walk through my important user journeys automatically, around the clock, so that I find out something is broken or slow before my customers tell me.
You'll find it under Synthetic Monitoring in the left navigation.
How it works
You describe a journey once — a website, how often to check it, and a list of steps (open this page, click this button, type into this box). CodeXray saves that as a job and runs it on a schedule in a real browser. Every run records pass/fail, how long it took, and how fast the page rendered.
| Step | What happens |
|---|---|
| 1. You create a job | A name, target website, how often to run, and the steps to perform. |
| 2. The scheduler runs it | Every 5 minutes, hour, or day — whatever the interval says. You can also run it by hand. |
| 3. A browser performs the steps | Invisibly, on a server. It times every step and notes the first one that fails. |
| 4. Results appear in CodeXray | Pass/fail, speed, availability over time, and which step broke. |
Key terms
| Term | Plain meaning |
|---|---|
| Job | One saved check — a name, a website address, an interval, and steps. |
| Run | One execution of a job. A job has many runs over time. |
| Step | One action inside a job: open a page (goto), click, type, upload a file, wait, or measure. |
| Selector | How the browser finds an element. CSS syntax: #username means "the element with id username"; .submit-btn means "an element with class submit-btn". |
| Interval | How often the job runs — 5m, 15m, 1h, 1d, and so on. |
| Latency | How long the whole run took, in milliseconds (1000 ms = 1 second). |
| Availability | The percentage of runs that passed in a time window. |
| Honeycomb | The grid of hexagons on the results page — one hexagon per recent run, coloured by result. |
Web-vitals it captures
Each run measures the same speed signals real-user monitoring uses:
| Signal | What it measures |
|---|---|
| TTFB | Time to first byte — how long the server took to start answering. |
| FCP | First Contentful Paint — how quickly the first content appeared. |
| LCP | Largest Contentful Paint — how quickly the biggest content appeared. |
| CLS | Cumulative Layout Shift — how much the page jumped around while loading (lower is better; no unit). |
| DOM Load / Page Load | How long the document, then the whole page, took to finish loading. |
Run statuses
Every run ends in one of these:
| Status | Meaning | Colour |
|---|---|---|
| Pass | All steps worked | Green |
| Partial | Some steps worked, at least one didn't | Amber |
| Fail | The run broke | Red |
| No data | The job has never run | Grey / — |
A Partial result means part of the journey succeeded and part didn't — for example, the page opened but a later click found nothing. It's a signal to look, not necessarily an outage.
How web-vitals are graded
FCP, LCP, and CLS each get a grade — Good, Needs Improvement, or Poor — using the standard Core Web Vitals thresholds:
| Signal | Good | Needs Improvement | Poor |
|---|---|---|---|
| FCP | ≤ 1.8 s | 1.8 – 3 s | > 3 s |
| LCP | ≤ 2.5 s | 2.5 – 4 s | > 4 s |
| CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
These grades appear next to each measurement on the job results page.
What's kept
- Run history is kept for 30 days. Older runs age out automatically — the honeycomb and charts show a rolling window.
- Job setups are kept until you delete them. Pausing or editing a job never loses its history; deleting a job removes its runs permanently.
Access and plan
| Who / what | What they can do |
|---|---|
| Editors / admins | Create, edit, run, pause, and delete jobs, plus view everything. |
| View-only users | See the jobs list and every result — but no pause switch, no action buttons, and no "Add job" (these are absent, not greyed out). |
| Plans without Synthetic Monitoring | Both pages show an upgrade message instead of an error or an empty table. |
Next steps
- Creating & Managing Jobs — build a journey step by step, then run, pause, and manage it
- Reading Job Results — the results page: runs, honeycomb, SLA summary, and web-vitals charts
- Alerts — get notified when something breaks (alerting is configured separately)