For agencies who look after client sites
A dashboard that has been green for six weeks and a dashboard that has not run for six weeks look exactly the same. Loop Assurance schedules a daily check on every client site in your tenant, writes what it finds into a page your client can read under your name, and tells you plainly which days it did not run.
The hard month in a retainer is not the month something breaks. It is the month nothing does, and the client asks what they are paying for. Four documents come out of this, and two of them are written for them rather than for you.
01
Goes to your client
One page per site in plain English under your name and logo: what is being watched, what has cleared since the last page, what changed, and what these checks cannot see. Rewritten every run, rendered as a branded PDF each Monday. It goes to the client when you run the send, and not before.
02
Goes to your client
Every run held for one site, in one document: the days checked against the days expected, what came up and what cleared with dates, the changes noticed, and the days nothing was checked. This is the page for the renewal conversation.
03
Stays with you
Every site at once: what needs a person, how long each item has been open, what cleared, the median days to clear, and which sites could not be verified. Written whether or not you have connected a channel.
04
Stays with you
Every site's findings in one list instead of one list per site, grouped by the condition and by the platform it was seen on, worst first: what is on nine of your sites, what turned up this week, and how long the oldest instance has been open. Grouped by what was observed, not by cause — two sites showing the same thing may need two different fixes, so a row is one investigation rather than one job.
05
Stays with you
Whether the loop is alive: when the last full run was, which of the last seven days did not run, whether anything is configured to page you, and when the next run is due. So you find out before your client does.
Your uptime monitor answers one question well: did the server respond. It is silent on the day www and the bare domain begin serving two different sites, or the sitemap starts listing pages on a staging host. These run against the homepage and what the homepage declares. Each is written here the way the product writes it — what it looks at, beside what it does not.
Reachability and identity
What it sees
What it cannot see
reachable
One GET of the homepage from one location: status, final URL, HTTPS, time to first byte.
Cannot see
Pages other than the homepage. Regional outages: this is a single vantage point. Slowness under load.
host-redirect
Whether the other host form, www against the bare domain, redirects rather than serving a second copy of the site.
Cannot see
Other aliases and old domains you have not registered here.
domain
The certificate's expiry and host match, and the domain's DNS: NS, MX, SPF, DMARC.
Cannot see
Registration expiry at the registrar. DKIM, which is selector-specific. Whether mail actually delivers. Chain trust beyond expiry and host match.
security-headers
Two headers on the homepage response: HSTS and X-Content-Type-Options.
Cannot see
Content-Security-Policy quality. Cookie flags. TLS configuration. Two headers are two headers, not a security review.
How machines read it
What it sees
What it cannot see
canonical
The canonical link in the homepage's server HTML, and whether it points at this host.
Cannot see
Canonicals on inner pages. Tags injected by client-side JavaScript. Whether Google agrees with it.
indexability
The robots meta tag and X-Robots-Tag header, against the intent you declared for this site.
Cannot see
Inner pages. Search Console removals or manual actions. Password-protected pages.
robots
robots.txt: whether it disallows everything, and whether it names a sitemap.
Cannot see
The effect of per-path rules. Crawl-delay semantics. Whether the named sitemap is the one Google uses.
sitemap
That the sitemap parses, and that up to 25 sampled entries are on the canonical host and answer.
Cannot see
Entries beyond the sample. For a sitemap index, the child sitemaps are checked, not the pages inside them. Whether lastmod is honest.
open-graph
The link-preview tags compatible apps read, and that the preview image fetches as an image.
Cannot see
How Facebook, LinkedIn or Slack actually render the card. Inner-page previews. Image dimensions and safe zones.
structured-data
That the structured data describing the business parses, its @type set, and that the URLs inside it resolve.
Cannot see
Validity against schema.org. Rich-result eligibility. Microdata and RDFa.
The page, and what it runs on
What it sees
What it cannot see
link-rot
A sample of the homepage's links answering: up to 30 internal and 15 external.
Cannot see
Links on inner pages. Soft 404s that answer 200. Hosts that block bots — those are recorded as unverifiable, never as dead.
forms
That a contact endpoint you registered answers an empty submission with the rejection status you registered.
Cannot see
That a real submission reaches an inbox. Spam-protection strength. Any form you have not registered.
a11y
Accessibility basics in the server HTML: page language, title, image alt text, link and button names, form labels, h1 count.
Cannot see
Colour contrast. Keyboard and focus behaviour. The screen-reader experience. Anything rendered by JavaScript. WCAG conformance — this is not an audit.
cwv
One PageSpeed Insights mobile lab run a day, plus Google's field data where it exists, when you supply a key.
Cannot see
Desktop. Inner pages. Day-to-day lab noise; a regression needs two runs against the baseline. With no key it reports itself not configured, which is a note, not a pass.
platform
What the site runs on, and on WordPress or Shopify up to five passive hygiene probes: a readable debug log, an open uploads listing, xmlrpc, the users endpoint, readme.html, the products feed.
Cannot see
Plugin and theme versions, or their known vulnerabilities. Admin-side settings. Anything behind a login. A probe a firewall blocks is unverifiable, not clean.
And since yesterday
What it sees
What it cannot see
change
Day over day: the homepage's title, description, canonical, robots directives, H1s, internal links, forms, structured-data types, preview tags, third-party script and stylesheet hosts, analytics ids, hreflang, and the detected platform.
Cannot see
Inner pages. Visual and layout changes. Copy below the H1, so publishing a blog post is not an incident. Anything changed and changed back between two runs.
A request that times out, is refused, or is blocked is recorded as unverifiable. It is never counted as a pass and never reported to your client as a fault on their site.
It will. A check will raise something that is not a problem on that particular site, and you will not want to explain it to your client every month for a year.
Accept it and it stays on the client page as being fixed, and is never raised at you again. Ignore it with a reason and it leaves the client page entirely. Both hold until a date you set, then come back — a decision that never expires is a decision nobody revisits.
A day with nothing new sends nothing. That is the whole escalation rule: you hear from it when something changed, not every morning.
Required
The addresses
The URL of each client site, and which host is the canonical one. Nothing else. No hosting credentials, no CMS login, no access to your clients' accounts. We check what you register against the real sites before it reports anything, so a mistyped path never becomes doubt about your client's form.
Optional
A contact endpoint per site
The path and the status a healthy route returns for an empty submission. Register one and the form is watched; skip it and the digest says the form is unmonitored rather than pretending it is fine.
Optional
A PageSpeed key, and a channel
The key turns on the mobile speed check. Slack or email turns on the same-day heads-up. Connect neither and everything is still written down — the status screen simply tells you, in those words, that nothing will page you.
Optional
Your brand
Logo, colours, typeface, legal line, report title. Ours are only the defaults you replace, so the keys you skip are the ones that still say 4ULoop.
Yours to do
Tell the client about the form probe
The one write we make against a site is an empty test submission to the endpoint you registered, once a day. Your client should know their form is being submitted to before they see it in a log.
It starts at the homepage and follows only what the homepage declares: robots.txt, the sitemap, a sample of links, the preview image, DNS and the certificate. One location, once a day, with no browser of its own — the mobile speed number comes from Google’s PageSpeed Insights. It does not see inner pages, does not measure performance under load, and does not confirm what a search engine or a social app actually displays.
Daily is a schedule, not a guarantee. The rollup counts the calendar days that had no full run and names them. A missed day is reported as a day nothing was checked — never absorbed into no news.
Runs, findings and reports for one agency stay in that agency’s tenant; the product never reads one tenant while working on another’s, and that boundary is tested. 4ULoop operates the runner and can see the runs. Nothing it produces is a legal certificate or a statement that a legal requirement has been met — it is monitoring and evidence.
Not a demo account — yours, so the first thing you read is about sites you already know. In our measured run, three sites took 71 seconds with the speed check and 32 without. You get the digest, a client page for each, and a talk track covering each site, worst first. If none of the monitored checks finds anything, it says so.
Send us three URLsLooking for a website rather than someone to watch one? That is the studio.