Skip to main content
9 min read

Golden-Path Monitors

Pro Feature

A Golden-Path Monitor is a business guardrail, not an uptime guarantee or a reliability certification. It watches the one route sequence that matters most for revenue — your signup or your checkout — and tells you when that path and real conversions break at the same time.

Golden-Path Monitors are available on Pro, Scale, and Enterprise plans. Upgrade your plan to enable this feature.

Read this before you rely on it. A Golden-Path Monitor 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, does not execute client-side JavaScript flows, does not submit forms or POST to your signup/checkout endpoints, and does not guarantee the flow works end to end. Treat it as an early-warning signal that pairs synthetic reachability with your real conversion data — not as proof your funnel converts.


What it does

Zenovay analyses your recent successful real sessions — sessions where a visitor actually completed signup or checkout — and derives the most common route sequence those visitors took. That sequence is your golden path, and it comes with a confidence score based on how consistently real converters followed it.

Once you confirm the path, Zenovay re-runs it on a schedule as a series of lightweight GET requests, recording per-step status, timing, and the first step that failed. It then correlates that synthetic result with your real conversion volume in the same time window. When both the synthetic checks fail and real conversions drop together, it raises a drift incident.

This dual-signal gate is the whole point: a synthetic check failing on its own is noisy (a route can 404 for a crawler and still work for users); a conversion dip on its own is ambiguous (could be a slow sales day). When both move together, something real is wrong with the path that earns you money.


How the golden path is derived

  1. Zenovay looks at recent sessions that ended in a successful signup or checkout for the website.
  2. It extracts the ordered sequence of routes (URL path patterns) each converter visited on the way to that success.
  3. It finds the most common sequence across those converters and computes a confidence score — how dominant that single sequence is among everyone who converted.
  4. It surfaces the suggested path, the confidence score, and which conversion type it represents (signup or checkout) in the Golden Path tab.

If there aren't enough successful sessions to derive a dominant sequence, Zenovay says 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; the suggestion appears once real converters give it a stable pattern.

Derivation runs on a daily schedule, but if you already have conversions you don't have to wait for it: the Setup tab has a "Check for a golden path now" button that runs the derivation immediately (rate-limited). It still only proposes a candidate path — you confirm it before any monitoring starts.


Setting it up

The Golden Path tab lives under the BEHAVIOR group in your domain dashboard.

1. Open the Golden Path tab → Setup

Zenovay shows the suggested route sequence it derived from your real converters, along with the confidence score.

2. Pick signup or checkout

If both a signup path and a checkout path qualify with enough confidence, you 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.

3. 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.


Check schedule (configurable)

How often Zenovay re-runs the confirmed path is controlled from the Setup tab of each active monitor via the "Check every" control:

  • Pro — locked at 60 minutes (hourly).
  • Scale & Enterprise — choose 5, 10, 15, 30, or 60 minutes per monitor.

5 minutes is the floor: the scheduler polls every 5 minutes and cannot run more often. The default when you first confirm a path is 60 minutes. A shorter interval gives you a faster signal when something breaks, but does not change the sensitivity of the dual-signal drift gate — that logic is unchanged regardless of how often synthetic runs execute.

Each run sends GET requests to the routes in the path in order, and records for every step:

  • Status — did the route respond as reachable?
  • Timing — how long the step took.
  • First failing step — the earliest step in the sequence that failed, if any.

The Health tab

The Health tab summarises the monitor at a glance:

  • Pass rate — share of recent scheduled runs where every step was reachable.
  • Last run — when the path was last re-run.
  • Average duration — mean total replay time across recent runs.
  • Slowest step — the route that consistently takes the longest.
  • First failing step — where the path most recently broke.
  • Drift summary — whether synthetic failure and a real-conversion drop are happening together right now.

Reading the Health view

The Health tab also shows a response-time chart — a green line of total replay duration (sum of all step timings) per scheduled run. Amber marks a degraded or slow run; red marks a failure. Below the chart is a recent-runs list showing approximately the latest 50 runs with per-run pass/fail, duration, and first-failing-step detail.

A date-range selector at the top of the Health view scopes everything together — the chart, the summary stats, and the recent-runs list. The available ranges depend on your plan's run-history retention:

RangePlans
Last 24 hoursAll paid plans
Last 7 daysAll paid plans
Last 30 daysPro, Scale, Enterprise
Last 90 daysScale, Enterprise
Last 180 daysEnterprise

Ranges longer than your plan retains are shown but locked. Run history retention: Pro retains 30 days, Scale retains 90 days, Enterprise retains 180 days.

Pass rate and timing describe route reachability only. A 100% pass rate means every route in the path responded to a GET; it does not mean a real user can complete signup or checkout (client-side JS, form validation, payment processing, and auth state are all outside what a reachability check can see).


Drift and incidents

Drift is the signal that turns this from a status page into a business guardrail.

Drift fires only when both are true in the same window:

  1. The scheduled synthetic checks are failing, and
  2. Real conversions for that path have dropped.

When drift fires, Zenovay raises an incident, visible in the Incidents tab alongside Conversion Incidents. The incident is classified into one of three failure classes:

Failure classWhat it means
infraThe site or network appears down — routes are unreachable broadly.
flow_driftA specific route in the path changed or now returns a 404 — the path moved out from under your funnel (e.g. a renamed /signup route).
business_flowRoutes are all reachable, but real conversions still collapsed — the breakage is behind the routes (broken client-side step, payment failure, 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.


What V1 does and does not do

To keep expectations honest:

V1 does:

  • Derive a single golden path from real successful sessions, with a confidence score.
  • Monitor one path per project — signup or checkout.
  • Re-run that path on a configurable interval (Pro: 60 min fixed; Scale/Enterprise: 5–60 min) as GET reachability checks.
  • Record per-step status, timing, and first failing step.
  • Raise a drift incident only when synthetic checks fail and real conversions drop together.
  • Classify failures as infra, flow_drift, or business_flow.

V1 does not:

  • Run a headless browser or execute client-side JavaScript flows.
  • Submit forms or POST to 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 simultaneously.
  • 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.


Was this page helpful?