release-aware reliability for revenue-critical journeys
Frontend Sentinel runs the journeys that make you money in a real browser after every release. It checks every buy button, search signal and page your customers depend on, opens one incident tied to the release that caused it, and keeps it open until the journey is proven to work again.
Early access for e-commerce, SaaS and digital product teams. No code on your site. Read-only by design: Sentinel never places a real order and never changes production.
store.example.com · desktop and mobile
the expensive blind spot
A 200 response proves that a server answered. It does not prove that a customer can click the right buy button, reach the right checkout, see the page at all, or find you in search tomorrow.
Sentinel watches the experience, not just the endpoint. It renders the live site in a real browser, runs the journey your customer actually takes, and checks what a visitor can see and click, not only what the HTML contains.
noindex or moves a canonical is an outage for organic revenue, and nothing alerts on it.found on our own sites
Sentinel was built on our own network of sales sites. An audit found these failures by hand. Each is now a check Sentinel runs on every page it watches, and each is part of the 20-breakage test it passes.
Buy buttons opened a different product's checkout. The page looked fine and every link "worked".
NowEach buy button is checked against the product it sits under, and against the checkout it must open.
Buttons pointed at #, or at a section of the page that did not exist. Clicking did nothing.
NowA buy link that goes nowhere is a finding on the first run that sees it.
One sales page's checkout was deleted. Every button on the page led to an error.
NowCheckout links are followed. On Gumroad, Sentinel can also ask the store whether the product is still published.
HTTP 200, title and heading in the HTML, buy links resolving. Every visitor saw an empty page, because one CSS class was missing.
NowSentinel compares what a visitor can see with what the page holds. Over 91 runs on 39 checks it flagged exactly those three pages, and nothing else.
A homepage linked 2 of 22 library pages in its server HTML. The rest appeared only after JavaScript, so search engines never found them.
NowLinks that exist only after JavaScript, lost titles and headings, noindex and moved canonicals are search incidents.
Tag managers, consent layers, payment widgets, A/B tools and chat scripts can all block a click or cover a button without a release.
NowNew or changed scripts and third-party domains are recorded with each failure, so a tag change shows up in the incident.
Honest by design: Sentinel first proves that the customer path broke and keeps the evidence. It ties the incident to a release when the timing and the changed files support it, says how strong that link is, and does not invent a cause the evidence does not show.
one loop from release to verified fix
Every release triggers an immediate run of your most critical checks, on top of the schedule. No deploy hook? Sentinel notices the deploy itself from the page.
A suspected failure is rerun in a fresh browser. Only what reproduces becomes a finding. One-off glitches are discarded and counted.
Related findings merge into one incident, tied to the release that preceded them, with the strength of that link stated.
A broken checkout outranks a moved footer. Priority follows journey criticality and how widely it fails, with the reasons shown.
After the fix, the affected checks run again. The incident resolves after two healthy runs on every affected screen size.
six signals from one browser run
One run records a screenshot, the page, console errors, failed requests, lab web vitals, search state and accessibility findings. Six detectors read the same record, so one regression becomes one incident, not three alerts.
A journey step or assertion fails, an element is missing, a page errors, a critical request fails, or the page renders blank for visitors.
Checkout links that 404, open a different product, go nowhere, or are all hidden. Store-level checks for Gumroad products that were unpublished or deleted.
noindex added, canonical moved, title or main heading lost, robots.txt now blocking the page, links visible only after JavaScript.
Pixel and layout change outside masked areas, and key elements such as the buy button pushed out of view.
LCP, layout shift and blocking time beyond budget or worse than the baseline. Labelled as lab values, never passed off as field data.
New axe-core violations at serious or critical level, so a release cannot quietly lock out keyboard or screen-reader users.
signal quality
Alert fatigue is how browser monitoring gets switched off. Sentinel's target is fewer than one false incident per site per week, and the dashboard measures it for you rather than asking you to trust it.
Fixed clock and timezone, animations off, fonts awaited, cookie banners handled by a rule per site, known ad and chat scripts blocked.
Mask rotating prices, dates and recommendation rails by selector. Sentinel suggests masks when an area changes between runs with no release in between.
Every suspected failure reruns in a fresh browser. If Sentinel's own network is slow across several sites at once, slowness findings are held, not blamed on you.
Comparisons run against an approved baseline per check and screen size, never against "the last run". An intended change is accepted in one click and recorded.
Revenue-critical journeys alert on any functional failure and small changes in key areas. Informational pages alert only on failures or large changes.
For example: "reproduced 2 of 2, outside 1 mask, 18% of the screen changed". Noise becomes something you can tune, not a mystery.
A monitor that tells you when it is blind. If Sentinel was not watching, because its runner had no network, it was stopped, or its checks stopped completing, it records the gap, tells your channel, and counts that time against itself. A check whose last result is overdue shows Unknown, never a stale Healthy. Your Reliability page shows false alarms per site per week, discarded noise and detection times.
safe on production
A monitor that places real orders or trips your firewall gets uninstalled on day one. Three rules make journeys safe to run against your live site.
Every journey step is read or write. Write steps run only as "stop before commit" (the buy button is checked, never clicked), with your test account, or on staging. Sentinel refuses to save a journey that does not say which.
Secrets are encrypted per organization, injected at run time and never shown again. One-time codes from a stored TOTP seed. Password fields, and any element you mark as personal data, are masked in screenshots and page copies.
A reachability check on day one tells you whether you need anything. If you do: a signed header per site that your WAF can allow, on any plan, or a runner inside your own network.
incident intelligence
Ready-made adapters for GitHub Deployments, Vercel, Netlify and Cloudflare Pages, a generic deploy webhook, and a command for any CI job. A finding is tied to the release before it, marked "strong" when the failing page's files changed in that release, "timing only" otherwise.
When a page's server HTML changes between runs, Sentinel records an observed release, runs your critical checks, and attributes to it. On our five sites: zero false releases across 74 comparisons.
Journey criticality from P0 (revenue) to P3 (informational), raised when most screen sizes or several journeys fail. No made-up revenue figures.
A new incident shows earlier ones on the same check or finding, and how each ended: fixed by which release, accepted as intended, or dismissed.
When a redesign moves a button, Sentinel proposes the element that best matches the last one seen, with its reasons. A person accepts it; nothing changes on its own.
catch it before it ships
Point Sentinel at a preview deploy and it runs the same checks against your production baseline: "would this break the buy button?" before anyone presses merge. Production is never touched, and a command for your CI pipeline returns pass or fail.
Preview addresses from Vercel, Netlify, Cloudflare and others, limited to hosts you list. Results come back as passed, changed, or would break.
It reads your site and proposes a purchase path for each checkout, plus sign-in, sign-up and email forms. Each proposal stops before commit, is tried once on your live site, and runs only after a person approves it.
Build steps as rows, check them without saving, and "try it once" for a per-step result with a screenshot. Unsafe journeys are refused before they run.
evidence packs and integrations
Every resolved incident carries an evidence pack: the baseline, the failing screenshot, the difference and the screenshot after the fix, with the timeline and the release. Incidents reach your team where it already works.
A readable page for engineering, a PDF for leadership, vendors or clients, and a structured record for your own tools.
Slack messages per incident, and a webhook for every incident event, signed so your systems can trust it.
One Jira issue per incident at or above the priority you choose, updated as it resolves. API tokens scoped to a project.
team and enterprise controls
where it fits
| Tool family | Strong at | What Sentinel adds |
|---|---|---|
| Synthetic monitoring | Scripted checks and alerting | Release attribution across visual, search, commerce and accessibility in one incident, and a close that needs proof |
| Visual testing | Screenshot diffs in CI | Runs on production after every deploy, ranked by how much the journey matters |
| Performance monitoring | Web vitals trends | Ties a vitals regression to the journey and the release that broke it |
| SEO change monitoring | Indexability alerts | Treats a search regression as a release incident with an owner and a verified fix |
| Uptime monitoring | Is the server answering | Can the customer see the page, click the right button and reach the right checkout |
current status, plainly
Frontend Sentinel is young. The features on this page are built and tested, and run on Cloudflare against our own sites. What we do not have yet is the measured 30-day run on design partners' sites. That is what the early-access pilot is for.
Watch a drill on our own live site. On 5 October 2026 we broke a buy button on purpose and deployed it. Sentinel opened a critical incident 1.92 minutes after the broken page went live, on desktop and mobile as one incident, and closed it itself 1.4 minutes after the fix went live, once it had seen two healthy runs on each. See every step, and what the recording does not show.
| Capability | Status | What that means today |
|---|---|---|
| Monitoring and the six signals | Built | Sites, page checks, journeys, baselines, masks, confirmation reruns and Slack, running on Cloudflare against our own sites. |
| Incident intelligence | Built | Release attribution, observed releases, priority, grouping and verified close. The 20-breakage test passes 20 of 20 on the test shop. |
| Before release and onboarding | Built | Preview checks, suggested journeys, the journey editor, selector repair and similar past incidents. |
| Enterprise controls | Built | Audit log, roles, custom roles per project, single sign-on (OpenID Connect), EU or US evidence storage, retention, evidence packs and webhooks. |
| Proven with real providers | In progress | Single sign-on and Jira are tested against test services, not yet a customer's Okta or Jira site. The self-hosted runner works; its container image is still to be built. SAML only if a customer's provider cannot do OpenID Connect. |
| AI explanations | Off for now | Built with the citation check, switched off until design partners join. Incidents use rule-based summaries meanwhile. |
| 30-day field proof | Recruiting | Design partners to measure false alarms, detection speed and incident usefulness on real production sites. |
pricing
A plan covers one production site and everyone who works on it. You are not charged per seat, per user or per run. What changes between plans is how many critical journeys you watch, how often the fastest ones run, and the controls your organization needs.
One site, the journeys that matter most, alerts in Slack.
Several journeys per site, faster checks where revenue is at stake, and the integrations an engineering team expects.
Control over your data, your people and where the checks run.
Annual billing gives you two months free. Agencies and consultants who bring Sentinel to their clients get a reseller rate. Design partners in the current round (five places) keep 90 days free, then 50% off the published price for their first 12 paid months, in exchange for a 30-minute call every two weeks about what Sentinel got right and what it got wrong. Design-partner terms.
Every plan is the same monitoring. Limits and controls are what differ. Prices are in US dollars and exclude any sales tax or VAT that applies where you are.
early-access offer
Do not monitor the whole company on day one. Pick the path that matters most, such as checkout, signup, payment, login or a lead form, and see whether Sentinel earns a place in your stack.
We set up your most valuable production journey with you, approve the baselines together, route incidents to your team and review what the first month showed.
The pilot exists to produce field evidence, not to lock you into a long contract.
For teams with several sites, private environments, procurement and security review, we scope a design-partner deployment around the controls that are already built.
questions serious teams ask
Uptime monitoring tells you whether a server answers. Sentinel runs your journeys in a real browser and checks what a customer can actually do: see the page, click the right buy button, reach the right checkout, and find the page in search. It ties each failure to the release that caused it and verifies the fix.
No. Every journey step is declared as read or write, and write steps only run as "stop before commit" (the final button is checked, never clicked), with a test account you provide, or on staging. Sentinel refuses to save a journey that does not declare one of these.
No. Failures must reproduce in a fresh browser before they alert, rotating content can be masked, and comparisons run against baselines people approved. Thresholds follow how critical the journey is. Every finding records why it got through, and false alarms are counted on your Reliability page.
It helps, and adapters exist for GitHub Deployments, Vercel, Netlify and Cloudflare Pages, plus a generic webhook. Without them, Sentinel still notices deploys from changes in your pages' server HTML and attributes failures to them.
They change the live page without an application release. Custom HTML tags, listeners, overlays and consent integrations can interfere with clicks or cover buttons. Sentinel detects the customer-facing failure, records new or changed scripts and third-party domains alongside it, and does not claim a specific tag caused it unless the evidence shows that.
Sentinel checks reachability on day one and tells you which route you need, if any. The usual route is a signed header per site that your WAF can allow on any plan. For strict networks or internal apps, an Enterprise self-hosted runner runs the checks inside your network.
No. There is no tracking script or SDK. Sentinel visits your site in a browser, as a customer would.
Screenshots and page copies of the pages checked, with password fields and any element you mark as personal data masked. Evidence is deleted on your tier's retention schedule. Enterprise customers can keep evidence in the EU or the US. Secrets are encrypted and never shown back.
No. Sentinel detects, explains, routes and verifies. People decide what to change.
It is built and switched off for now. Incidents use rule-based summaries, and the product does not depend on AI to be useful. When it is on, every statement must cite stored evidence, and statements that do not are removed in code. Enterprise customers can use their own model key or keep it off.
Per site, with the number of journeys and the fastest check frequency set by the plan: $99 a month for Team, $299 for Business, and Enterprise from $1,500 a month billed yearly. You are not charged per seat or per run, and annual billing gives two months free. Early-access pilots are scoped individually. See pricing.
Sustained field use: a measured 30-day run on design partners' sites for false alarms, detection speed and usefulness. Single sign-on and Jira still need their first real customer setups, and the self-hosted runner's container image is still to be built.
early-access waitlist
Tell us your site and the one path that matters most. We will set up the pilot, approve the baselines with you, and start producing the evidence that tells both of us whether Sentinel belongs in your stack.
We email you when early-access and design-partner places open. Only your address is sent to our mailing list, and you can unsubscribe from any email. Prefer to talk first? Ask for a demo, or read the design-partner terms.