Getting started

Your first monitor

Add a site, choose what CheckRoost checks about it, and know what the first hour looks like.

A monitor is one site. The checks behind it are the questions CheckRoost asks about that site, each on its own schedule. Every check runs for the first time as soon as you save, so the page fills in within a minute.

Adding it

  1. Step 1. Open Add monitor

    Monitors→Add monitor.
  2. Step 2. Give it a name and an address

    The name is what alerts and the list call it. For the address, example.com is enough: https is assumed when you leave it off. Private and internal addresses are refused, because CheckRoost only ever connects to the public internet.
  3. Step 3. Choose the checks

    Uptime and Certificate health are ticked to start with. The rest are below.
  4. Step 4. Add a group and tags if you have more than a handful of sites

    A group sections the dashboard, usually one per client. Tags are labels such as WordPress or WooCommerce; alerts will be routed on them, so they are worth keeping consistent.

The checks

  • Uptime — requests the page and records whether it answered and how fast, every 30 seconds to every hour. The response-time chart, the security headers and WordPress detection come from it. Leave it off to watch only a domain’s DNS and registration, for a site you do not host or whose firewall turns CheckRoost away.
  • Certificate health — daily. Warns 30 days before expiry and fails at 7, and reads the whole chain the server sends.
  • DNS records — hourly, asked of the domain’s own nameservers. Tells you when a record changes.
  • Domain registration — daily. Expiry, the registrar and the transfer lock. Connect a GoDaddy account and it also says whether the domain will renew itself.
  • Broken links and Mixed content — daily, from one crawl of the site. They warn rather than fail: a dead link is a content problem, not an outage.
  • Sitemap — daily. Warns when the sitemap suddenly shrinks, which is what a broken plugin update looks like, or suddenly grows, which is what spam pages added by a break-in look like.
  • Lighthouse — daily scores for performance, accessibility, best practices and SEO.
  • Accessibility — weekly, the automated WCAG rules on the homepage and up to nine more pages, at phone and desktop width, in plain words. Warns on new critical or serious problems; never a compliance rating.
  • Blocklist — every six hours, the domain and its addresses against ten blocklist and filtering services. Behind a CDN the addresses are the CDN’s; connect Kinsta or Cloudflare and it measures the real server instead.
  • Application health — reads a JSON document the site publishes about itself and checks what is in it. The CheckRoost WordPress plugin publishes one.
  • Scheduled task — for a cron job: it calls a URL when it runs, and not hearing from it is the alert.

Advanced uptime settings, under the fold, set the timeout and a word the page must or must not contain — for catching an error page served with a 200.

What the first hour looks like

Each check runs once straight away and then on its own schedule. A failure is not believed on first sight: until it is confirmed the monitor reads Degraded, and only a confirmed failure makes it Down. One vantage point cannot tell “the site is down” from “our path to it had a moment”, and an alert that is wrong half the time teaches people to ignore it. A warning — a certificate expiring, a dead link — is reported the first time it is seen, because it will not go away on the next run.

Down is only for what cannot be reached: the site, a scheduled task, a server. Any other check that fails reads Failing, so a site serving every page is never called down over a certificate.

Is it WordPress?

If the first uptime probe recognises WordPress, the monitor offers Connect WordPress. The CheckRoost plugin then reports plugin and theme updates, PHP and WordPress versions, and files on the server that should not be public.