A Golden-Path Monitor watches the single route sequence that matters most for your revenue — your signup or your checkout — and warns you when that path and real conversions break at the same time.
What a Golden-Path Monitor is (and is not)
A Golden-Path Monitor is a business guardrail, not an uptime guarantee or a reliability certification.
It replays HTTP route reachability: it sends GET requests to the routes in your path and records whether each one responds. It does not:
- Run a headless browser
- Execute client-side JavaScript flows
- Submit forms or
POSTto your signup/checkout endpoints - Guarantee the flow works end to end
Think of it as an early-warning signal that pairs synthetic reachability with your real conversion data — not as proof your funnel converts.
Plan requirement: Golden-Path Monitors are available on Pro, Scale, and Enterprise plans.
How the golden path is found
Zenovay analyzes your recent successful real sessions — sessions where a visitor actually completed a signup or checkout — and works out the most common route sequence those visitors followed:
- It looks at recent sessions that ended in a successful signup or checkout.
- It extracts the ordered sequence of routes each converter visited on the way to that success.
- It finds the most common sequence and computes a confidence score — how dominant that one sequence is among everyone who converted.
- It surfaces the suggested path, the confidence score, and the conversion type (signup or checkout) in the Golden Path tab.
If there aren't enough successful sessions to derive a dominant sequence, Zenovay tells you so plainly — it will not suggest a low-confidence path. You'll see a "not enough successful sessions yet" state instead of a guess. Keep tracking and the suggestion appears once real converters give it a stable pattern.
Run derivation now: The Setup tab has a "Check for a golden path now" button that triggers derivation immediately (rate-limited) instead of waiting for the daily schedule. It still only proposes a candidate — you confirm it before monitoring begins.
Setting it up
The Golden Path tab is in the REVENUE group of your domain dashboard.
- Open the Golden Path tab → Setup. Zenovay shows the suggested route sequence and its confidence score.
- Pick signup or checkout. If both qualify with enough confidence, choose which one to monitor. V1 monitors one path per project — signup or checkout, not both. Pick the one that matters most for your business.
- Confirm the path. Review the steps and confirm. From that point Zenovay schedules the synthetic re-runs.
You confirm the derived path; you don't hand-author routes in V1. If the derived path looks wrong, that usually means your real converters are taking a path you didn't expect — which is itself a useful finding.
How often it re-runs
The re-run interval is user-configurable per monitor via the "Check every" control on the Setup tab of an active monitor.
| Plan | Available intervals |
|---|---|
| Free | Not available |
| Pro | 60 minutes (fixed) |
| Scale | 5 / 10 / 15 / 30 / 60 minutes |
| Enterprise | 5 / 10 / 15 / 30 / 60 minutes |
The minimum interval is 5 minutes — that is how often the scheduler polls. The default when you confirm a monitor is 60 minutes. Choosing a shorter interval gives you a faster signal when something breaks; Scale and Enterprise plans can pick any of the five options per monitor. A lower interval means more checks run per day, but it does not change how drift sensitivity is calculated.
Each run sends GET requests to the routes in order and records, for every step: the status (was the route reachable?), the timing, and the first failing step (if any).
Reading the Health tab
The Health tab opens with four summary cards:
- Pass rate — share of recent scheduled runs where every step was reachable.
- Last run — when the path was last re-run.
- Average duration — mean replay duration across recent runs.
- Drift — whether synthetic failure and a real-conversion drop are happening together right now (shown as "calm" or "degraded").
Below the cards, the recent-runs list shows each run individually. Expand a run to see the per-step status, timing, and the first failing step (where that run broke, if it did).
Response-time chart
The Health view includes a response-time chart showing replay duration per run. Runs are colour-coded: green = normal, amber = slow or degraded (completed but slower than baseline), red = failure. The recent-runs list below the chart shows up to the latest 50 runs, each expandable to per-step status and timing.
Date-range selector
A date-range selector at the top of the Health view scopes all data shown. Available ranges are gated by your plan's data-retention window:
| Range | Plans |
|---|---|
| Last 24 hours | All paid plans |
| Last 7 days | All paid plans |
| Last 30 days | Pro, Scale, Enterprise |
| Last 90 days | Scale, Enterprise |
| Last 180 days | Enterprise |
Ranges longer than your plan's retention window are shown as locked. The selector scopes the entire Health view — pass rate, chart, average duration, and recent-runs list all update together.
Pass rate and timing describe route reachability only. A 100% pass rate means every route responded to a GET — it does not mean a real user can complete signup or checkout. Client-side JavaScript, form validation, payment processing, and auth state are all outside what a reachability check can see.
Drift alarms and incidents
Drift is the signal that makes this a business guardrail rather than a status page.
Drift fires only when both are true in the same window:
- The scheduled synthetic checks are failing, and
- Real conversions for that path have dropped.
When drift fires, Zenovay raises an incident, and the Health tab links you straight to it in the Incidents tab.
Each run that fails is also tagged with one of three failure classes, shown as a badge when you expand the run in the Health tab. The class tells you where the breakage is:
| Failure class | What it means |
|---|---|
| infra | A route timed out, returned a 5xx, or was unreachable — likely a hosting or network problem, not your funnel. |
| flow_drift | An intermediate step now 404s, 410s, or redirect-loops while the entry route is fine — a URL in the path probably moved (for example, a renamed /signup route). |
| business_flow | Every route responded, but the real success signal (a completed signup or payment) was not corroborated in the same window — the breakage is behind the routes (a broken client-side step, a payment failure, a validation bug) that a reachability check can't see directly. |
The business_flow class is exactly why the dual-signal gate matters: reachability alone would have reported "all green" while your revenue was dropping. Pairing it with real conversion data catches the failure a pure synthetic monitor would miss. It also keeps alarms quiet — a synthetic failure on its own never alerts, because routes can 404 for a crawler and still work for users.
What V1 does not do
To keep expectations honest, V1 does not:
- Run a headless browser or execute client-side JavaScript flows
- Submit forms or
POSTto signup/checkout endpoints - Guarantee the flow works end to end, or certify uptime, reliability, or compliance
- Monitor more than one path per project, or both signup and checkout at once
- Alert on synthetic failure alone (by design — that would be noisy)
This is a guardrail to tell you when the path that earns you money is in trouble. It is not a substitute for end-to-end functional testing of your signup or checkout.