Evidence-led fault detection · United Kingdom
FaultFound checks the journeys your customers actually use — buying, booking, enquiring, getting in touch — and finds the ones that fail. When we find something, we show you the affected page and the evidence behind it before we ask you for anything.
Had an unexpected email from us? See exactly what we did and didn't look at
example-retailer.co.uk · 23 routes checked
Customer-impacting findings Last check 09:42
Next re-check 15 Aug, 06:00
Checks run the same way on
We test the way a customer browses, so the platform makes no difference to whether we can find a fault — only to how we describe the repair. Names shown are the property of their owners; no partnership or endorsement is implied.
The difference
An uptime checker asks whether the server responded. That is a useful question, but it is not the one your customers care about.
Requests the homepage. Confirms it responded.
Correct, and completely silent about whether anyone can actually buy anything.
FaultFoundWalks the journey a customer would take, then verifies what failed.
Website online — but the checkout fails once the customer picks a delivery option.
Illustrative example using a fictional domain. Real findings are tied to a specific URL on your own website.
What we look for
Every check is aimed at one question: can a customer still buy, book or get in touch? If a problem does not affect that, it does not become a finding.
The path from finding a product to completing a purchase.
The routes a prospective customer uses to reach a human.
Appointment, table, room and reservation journeys.
Server and delivery faults on commercially important pages.
Structural problems that strand someone mid-visit.
Front-end failures that block an action the customer needs.
Noise is the reason most automated audits get deleted. The system is tuned to discard anything that does not change what a customer can do — and to re-check anything that might simply have been a bad moment.
How FaultFound works
Nothing reaches a business until it has survived every stage. Most candidate findings are discarded long before anyone hears from us.
Our systems build a queue of publicly listed UK business websites. Nothing private is involved — these are sites already published for customers to find.
We follow the same publicly accessible routes a prospective customer would: product and service pages, baskets, booking links, contact and enquiry paths. We browse. We do not submit.
A single bad response proves nothing. Anything that looks like a fault is checked again later, and separately confirmed in a real browser, so a momentary wobble or a bot block never becomes a finding.
Confirmed faults are scored on two separate axes: how much it affects a customer, and how certain we are. Both are shown to you. We keep them apart deliberately — a serious-looking signal we are unsure about should not read like a certainty.
We record the exact URL, the HTTP response, timestamps for each observation and the browser-level confirmation. That evidence is what you inspect — it is the product, not a sales aid.
If — and only if — a finding survives everything above, the business receives a private link to its own report. It is not shared, indexed or published, and there is no charge for reading it.
You decide. If the finding is useful, you can buy the repair pack: the diagnosis, the likely root cause, the implementation steps and a verification checklist your developer can work from. If it isn't useful, you owe us nothing.
Evidence first
Every report is anchored to one specific page on your website and what happened when we visited it. No scores out of ten for things you cannot verify. No vague "issues detected".
The basket and the first checkout screen behave normally. The failure appears only once a delivery option is selected — which is why it survives casual testing.
https://example.co.uk/checkout?step=delivery
Demonstration data on a fictional domain.
Scope and boundaries
If you have just received an unexpected email about your website, this is probably the section you want. We look at your website the way a customer would. Nothing more.
Why these go unnoticed
Almost every fault we confirm has been sitting there for a while — not because anyone ignored it, but because of how websites are built, changed and watched.
Everyone checks the front door. Faults live further down the journey, where fewer people go.
A single broken listing out of four hundred is invisible from the outside — and can still be your best seller.
It only surfaces after a size, a date or a delivery option is chosen. That is three clicks past where most testing stops.
The team knows where everything is. Nobody arrives cold, searches, adds to basket and tries to pay.
The server is up, so the alert never fires. Nothing is watching whether the checkout still completes.
Platforms update themselves. A change that works on one theme can break a route on another.
Search results, old emails and printed material keep sending people to pages that quietly stopped existing.
Almost nobody emails to say the checkout is broken. They assume the business is closed, and go elsewhere.
Example scenarios
These are illustrative examples built to show the shape of a typical finding. They are not customer case studies, and no real business is described here.
The basket loads. The first checkout screen loads. Selecting a delivery method returns a server error, so the order can never be completed. The homepage, meanwhile, is perfectly healthy.
/checkout?step=deliveryA restaurant moved booking provider. The main navigation was updated, but the large "Book a table" button on the homepage still links to the retired system, which now returns 404.
/book-a-tableA single product page returns a persistent server error while every other page responds normally. Nothing in the site's monitoring notices, because the site itself is emphatically online.
/products/workbench-1800The contact page itself is healthy, so it passes every superficial check. The form's submission endpoint returns an error, meaning enquiries are lost between the customer pressing send and anyone reading them.
/contact/enquiryPricing
The price reflects the commercial impact and complexity of the confirmed finding. The exact figure for your finding is shown on your private report, before you decide.
Standard
£199
A clear customer-facing fault with a straightforward repair path.
High impact
£299–£399
An important commercial route affecting sales, bookings or enquiries.
Critical
£499
A severe, reproducible failure on a critical commercial journey.
Reading your report is free and always will be. If the fault has already been fixed, or you don't think it is worth repairing, don't buy it — there is nothing to cancel and no account to close.
How we earn trust
We are a young company. Rather than borrowing credibility we haven't earned, here is exactly how we operate — every line of it verifiable from your own report.
Your report shows the affected URL and the responses we recorded above the payment section, not after it.
Open the URL in your report yourself. It is a page any visitor can reach without logging in.
Each observation is listed with its own timestamp, so you can see the fault was seen more than once.
The tiers are published on the public pricing page — not invented per customer.
Every report carries a confidence percentage, including the findings we are less sure about.
Prices in pounds sterling, support in UK working hours, and a checking queue built from UK listings.
View the source of your report page: it carries noindex, and /offers/ is disallowed in our robots.txt.
Ask once. You receive one confirmation and nothing after it — no retention offer, no follow-up.
The payment screen is our provider's, not ours. Card details never reach FaultFound.
If any line above turns out not to be true, tell us and we will either correct the behaviour or remove the claim from this page. Both are better outcomes for us than being caught overstating something.
Check our work
Every finding we send names one page on your website and exactly what happened when we visited it. You can open that page, follow the same steps, and see for yourself whether we were right — in about a minute, before you spend anything.
Who is behind FaultFound
FaultFound is not a large agency, and we are not going to pretend otherwise. It is a focused engineering effort: automated discovery and browser-based checking at scale, sitting behind verification rules written by people who would rather send you nothing than send you noise.
The system does the volume. The rules decide what is worth your attention. Every threshold in it exists because a false positive would waste your time — and cost us the only thing we actually have, which is being right.
Builds and maintains the queue of publicly listed UK business websites to check.
Walks public customer journeys in a real browser and records exactly what happens.
Decide what counts as a fault, what is noise, and what has to be re-checked before anyone is contacted.
Keeps the URL, responses and timestamps attached to each finding so it stays checkable.
Answers questions about a report, a finding or an opt-out request.
Contact details on the contact pageOpen the private link in your email to see the finding, the affected page and everything we recorded. Reading it costs nothing, and there is no account to create.