Documentation

Catch a broken page that still loads

Uptime monitoring usually asks one question: did the page answer? Many of the problems that cost a website visitors and orders still pass that test. The shop's product grid renders empty. The CMS shows its error message inside the normal layout. A maintenance banner stays up after the maintenance. A release ships the staging configuration, and with it <meta name="robots" content="noindex">, and the site drops out of search results over the following weeks.

Pingsured reads the HTML and checks the elements you name — with the CSS selectors you already use in your browser's developer tools.

What to check

A check can also read an attribute instead of the text: link[rel=canonical] with the attribute href equal to your page's own address catches a canonical tag that points somewhere else. Where a page prints when it was last updated, such as time[datetime] or an article:modified_time meta tag, the age operators tell you when that date is older than it should be.

Text is compared with its whitespace normalised, so a line break or indentation change in the template does not set off an alert. If you prefer XPath to CSS, each check can use either.

Why check your pages with Pingsured

• It catches what visitors would see. Not only "the server answered", but "the page has its products, its prices and no error message".
• Search problems on the next check, not the next crawl. A noindex or a wrong canonical tag is caught within the check interval — minutes, rather than the weeks it takes to show up as lost traffic.
• Selectors you already know, combined freely with the status code, a text match and header checks; the ping passes only when all of them do.
• Each location on its own. A page that a CDN edge serves stale, or that a firewall rule blocks in one region, fails from that location without being hidden by the others.
• Easy to keep out of your analytics. Every request carries the User-Agent Pingsured/1.0, and our checks run from published addresses.

Limits worth knowing

• Checks read the HTML your server sends; they do not run JavaScript. Content that a single-page application renders in the browser is not there to check — check the API it loads its data from instead.
• Only the first 1 MB of the page is read. HTML that continues past it is checked as far as it goes, so an element near the end of a very large page may not be found.
• Checks send GET or HEAD and can add request headers and HTTP basic authentication. Pages behind a login form cannot be checked.