Fire Watch
Search and security monitoring
Know when your site is broken, not just when it goes down.
Fire Watch checks the pages, feeds, sitemaps, tags, and records that keep a publisher’s site visible, and tells you when a rule breaks. Buy it on its own, or with Quartermaster so the alert goes to the people who fix it.
For the digital lead whose uptime monitor said everything was fine while traffic fell.
Trusted by editorial teams at
A working homepage does not tell you whether the whole site works.
The homepage loads, so the uptime monitor is green. Meanwhile the CDN is serving cached pages over a crashed server. A staging push left canonicals pointing at the wrong hostname. Your analytics tracking has stopped working. The tag container is still on every page, but no visits have been recorded for three weeks. Scheduled posts stopped publishing. The certificate renewal failed on Friday night.
Each of these costs you readers or data for exactly as long as nobody notices. Most publishers notice in Search Console, weeks later.
Rules, not changes. Twice before we call. Every template, not just the homepage.
Fire Watch checks rules. A homepage title changes for good reasons, so we don’t alert on that. We alert when a rule breaks: a canonical pointing to another domain, a sitemap that stopped updating, a robots.txt that now blocks everything.
One failed fetch is usually noise, so we wait for two failures in a row. We check one page of each template, so a broken article template can’t hide behind a healthy homepage. And we check that data arrives, not only that tags exist, because a container can be present while analytics records nothing.
Availability
Public pages through the CDN, and the origin server behind it. The 404 page returns a 404. HTTP redirects to HTTPS in one step, and the wrong hostname redirects to the right one. The site’s scheduler reports in on a fixed interval, so you know when scheduled posts and tasks have stopped.
Crawling and indexing
Robots.txt returns and still references the sitemap, with an alert on any change. No noindex on sample pages. Canonicals present, self-referencing, and on the production hostname. No staging addresses in canonicals, social tags, sitemaps, or feeds. The XML sitemap parses, stays within range of its baseline, and lists fresh pages that return 200. The news sitemap, where you have one, holds only the last 48 hours. RSS feeds parse and point at production.
On the page
Titles present and not a WordPress default. Descriptions where the template needs them. Large image previews allowed, which Google requires for Discover. Open Graph tags present, with an image that loads and is at least 1,200 pixels wide. Structured data that parses and carries the fields an article needs: headline, dates, author, image.
Analytics
The expected tag container appears exactly once per page. The expected analytics ID is in the published container, with no second tag hard-coded. Yesterday’s sessions are within range for that weekday.
Domain and infrastructure
Domain expiry at 60, 30, and 7 days. Any change to nameservers, mail records, or the origin’s address. Mail authentication records still present. The domain is not on Google’s malware list. Core Web Vitals field data stays in Google’s “good” range.
Security
Certificate expiry at 30, 14, and 7 days, with every hostname you serve covered and the full chain valid. New administrator accounts, accounts that gain administrator rights, and administrators who haven’t signed in for 90 days. Your CMS, plugin, and theme versions checked daily against published vulnerability reports, including CVE records, with an alert when one affects your site and a fix exists.
Scope and alerts
Fire Watch covers one agreed site. When a rule breaks and stays broken, the contacts you name get an email that says which rule failed, on which page, and what to do about it. It reads as a paragraph, not an error code.
Fire Watch does not repair what it finds. Repairs are Quartermaster, your own developer, or a Site Survey sprint. On its own, we price Fire Watch in the proposal. With Quartermaster it is included.
Fire Watch watches. Quartermaster fixes.
On its own, Fire Watch tells you and your developer what broke, where, and what the rule is. Every Quartermaster site includes Fire Watch, so there the alert goes to the people who maintain the site, and repairs are part of the service.
Set up for your site
At onboarding we confirm the checks for your site, set their baselines, and agree on how often they run and who receives alerts. News sitemaps, event publishing, and language checks apply where your site uses them.
Questions
We already have an uptime monitor.
Keep it if you like. It answers whether the homepage loads. Fire Watch answers whether the site still works for search, analytics, and distribution, which is where publishers lose readers without noticing.
Will you fix what you find?
On a standalone subscription, no. We tell you what broke and what the rule is, and your developer fixes it. With Quartermaster, we fix bugs in your site. New features, pages, and redesigns are scoped separately.
Does every site need every check?
No. We match the checks to your templates, integrations, and publishing setup. A site without a news sitemap or multiple languages does not need those checks.
Will we get alert noise?
We check rules rather than changes, and we wait for two failures in a row. We set baselines per site, so a redesign doesn’t trigger a flood.
What access do you need?
Read access to Search Console and Analytics, the list of templates to sample, and a read-only connection to your site for the account and version checks.