What uptime monitoring reports
One request to the homepage, every few minutes.
GET https://example.co.uk/
200 OK
All systems normal
True. Also true while every order on the site is failing.
How FaultFound finds a fault, proves it, and gets out of your way.
The whole system is built around one idea: a finding is only worth sending if the business can check it themselves. Everything below exists to make that true.
What FaultFound reports
The commercial routes, walked in order, then verified.
/ → 200 OK
/products/… → 200 OK
/basket → 200 OK
/checkout?step=delivery → 500
re-check + browser → confirmed
A named page, a named failure, and proof it wasn't a one-off.
Illustrative example on a fictional domain.
The process
Seven stages. Most candidates never get past stage three.
The stages below are ordered by cost: the cheap checks run first and discard the bulk of the queue, so the expensive verification work only ever runs on things that already look real.
1
Discovery
We build and maintain a queue of publicly listed UK business websites — the same ones a customer would find through an ordinary search. Nothing private, purchased or scraped from behind a login is involved.
2
Customer journey analysis
We follow the routes that matter commercially — product and service pages, baskets, checkout steps, booking links, contact and enquiry paths — in the same order a prospective customer would. Pages are loaded in a real browser so that JavaScript-driven journeys behave the way they do for a visitor.
We browse. We never submit. No form is sent, no order is placed and no booking is made.
3
Verification
This is the stage that decides whether FaultFound is useful or annoying. A single bad response proves nothing — servers hiccup, deployments happen, bot protection blocks automated traffic. So every candidate fault has to survive being checked again after a delay, and has to reproduce independently in a browser.
Anything that clears on the re-check is discarded silently. You never hear about it, which is the point.
4
Impact assessment
A confirmed fault gets two independent scores. Severity asks how much this affects a customer trying to do business with you — a failed checkout outranks a broken link to an old blog post. Confidence asks how certain we are that it is real and reproducible.
We keep them apart on purpose. Collapsing them into one number is how audits end up claiming certainty they do not have.
5
Evidence capture
We record the exact URL, the HTTP status and response headers, the times of each observation, and what the browser did when it loaded the page. That record is the deliverable — it is what lets you check our work instead of taking our word for it.
6
Private report
Only findings that survive every stage above result in contact. The business gets a private link to a report about its own website: what we found, where, what we saw, how sure we are, and what it would cost to have it diagnosed and repaired.
The report is unlisted and not indexed by search engines. Reading it costs nothing and creates no account.
7
Repair
Your decision, made with the evidence already in front of you. If the finding is useful, the repair pack gives you the diagnosis, the likely root cause, the implementation steps and a verification checklist — written so your own developer or agency can act on it directly.
If it isn't useful, or you've already fixed it, you owe us nothing and there is nothing to cancel.
Scope and boundaries
Everything we see, any visitor could see.
FaultFound is not a security scanner and does not behave like one. We look at public pages, the way a customer would.
✕ We do not
- Log into private systems or admin areas
- Guess, test or attempt passwords
- Bypass authentication or access controls
- Attempt to reach private or customer information
- Submit payment or card details
- Place real orders or make real bookings
- Send enquiry forms or contact messages
- Deliberately interfere with, load-test or disrupt a website
- Perform destructive or intrusive security testing
✓ We do
- Visit pages already public to any visitor
- Follow links a customer could follow
- Record the responses those pages return
- Re-check anything that looks like a fault
- Respect robots directives and sensible request rates
- Keep each report private to the business it concerns
- Stop on request, permanently
- Show the evidence before asking for payment
- Say plainly when we are not certain
Being wrong is expensive
Why the system is tuned to say nothing.
An automated audit that cries wolf gets deleted, and deserves to be. Every threshold in FaultFound exists because a false positive costs you time and costs us the only asset we have.
Nothing acts on one observation
A fault must reproduce on a later, separate check before it can become a finding.
Two different methods must agree
A direct request and a real browser both have to see the same failure.
Bot blocking is not a fault
Being challenged by a firewall says something about us, not about your website.
Transient errors get a second chance
A single 5xx during a deployment is normal. We wait, then look again.
Commercial weighting
A broken checkout and a broken link to an old post are not the same problem.
Uncertainty is published
Confidence is shown as a number on your report, including when it is low.
If a finding turns out to be wrong, tell us. We will withdraw it, explain what
the system got wrong, and it will not be raised again. That is a better outcome for
us than arguing about it — see the FAQ for what happens next.
See what a finished report actually looks like.
The sample report is built from demonstration data on a fictional domain, but its structure is identical to a real one.