Frequently Asked Questions

Uptime, checkout/contact page reachability, and content tampering checks all run about once a minute. SSL certificate and domain registration are checked about once a day — those change slowly, so there's no benefit to checking them more often. Page speed works a little differently: we're always watching for your site responding slower than it normally does, and if it does, we run a deeper speed check right away rather than waiting; every site also gets at least one fresh speed score every day as a baseline regardless.

If a problem is ongoing (say, your site is down for 10 minutes), our checks keep detecting it on each pass — that's what confirms it's still happening, not a one-off blip. We collapse this for email alerts (you get one email per incident, not one per minute), but the "Recent findings" list on your Insights page still shows each individual check, with a full timestamp, so you can see exactly how long something lasted.

It's a simple, ever-increasing count of every check we've actually attempted against your site, going back to the day you started watching it. It's there so you can see, concretely, how much work is happening in the background on your behalf.

Your homepage returned an error instead of loading normally. "Server error" means it returned an HTTP 500 — usually a bug or crash on your own site or application. "Site unreachable" covers HTTP 502, 503, or 504 — typically your hosting or server is overloaded, restarting, or temporarily down.

This is different from the errors above, where your server responded but with a problem. Here, we weren't able to reach your server at all — usually a DNS issue (your domain isn't pointing where it should) or your hosting being completely offline, rather than an error on a page that did load.

Two different things, both under the same finding type: either a single check found your homepage responding noticeably slower than it should, or your PageSpeed score has stayed in poor territory across several checks in a row rather than just dipping once. The second one specifically means a sustained problem, not a one-off slow moment — a single slow check by itself won't trigger this from the PageSpeed side.

It's based on Google's own scoring system for real-world page performance on mobile — a widely used, independent standard for load time, rendering, and responsiveness, not something specific to us. We run it against your homepage on a regular basis so you always have a current score without having to think about it.

You'll get an "expiring" alert once your certificate has 14 days or less left. If it actually expires before you renew it, you'll get a separate, more urgent "expired" alert — an expired certificate means visitors' browsers will show them a security warning before they can even reach your site.

Most sites never need to do anything by hand. If your host provisions certificates automatically (cPanel's AutoSSL, most managed hosts) or you're behind a CDN like Cloudflare, your certificate typically renews itself before it expires — this alert is really a safety net in case that automatic process ever silently fails, not a sign you're expected to act every time.

If you manage it yourself with Certbot/Let's Encrypt directly on your own server, there's usually already an automatic renewal job scheduled (a cron entry or systemd timer running certbot renew) — a warning here is a good prompt to check that job is actually still running, since a broken renewal job often fails quietly with no other symptoms. To renew right now by hand, run certbot renew yourself, or look for a "renew SSL"/"reissue certificate" button in your hosting control panel.

If you bought the certificate directly from a certificate authority or registrar rather than getting it free and automatic, you'll need to log into that account, renew or reissue it there, then install the new certificate through your host's control panel — that install step doesn't happen on its own the way it does with AutoSSL or Let's Encrypt.

You'll get an "expiring" alert once your domain has 30 days or less left on its registration. If it lapses entirely, you'll get an "expired" alert — this is one of the most disruptive things that can happen to a business, since your whole site and any email tied to that domain can go down until it's renewed.

The best fix is turning on auto-renew in your registrar account (GoDaddy, Namecheap, Cloudflare Registrar, Squarespace Domains, and similar all offer this) and keeping the payment method and contact email on file current. A surprising number of "auto-renewing" domains still lapse anyway because a saved card expired and the renewal charge silently failed — auto-renew being turned on doesn't help if there's no way to actually collect payment when the day comes.

To renew manually right now, log into whichever registrar you originally bought the domain through — not necessarily your web host, since those are often two different companies — find the domain, and there's normally a direct "Renew" option to extend it by a year or more immediately. If you're not sure who that is anymore, a WHOIS lookup for your domain will usually show the registrar, or check old renewal-charge emails/receipts in your inbox.

The specific page you told us handles checkout or contact submissions didn't load correctly — even if the rest of your site is fine. This is checked separately from general uptime specifically because a broken checkout page can quietly cost you sales for hours before anyone notices, even while the homepage looks completely normal.

If your whole site is already down, we don't also raise a separate checkout or contact finding for the same outage — it would just be telling you the same thing twice. Once the rest of the site is back up, checkout and contact pages are checked independently again as usual.

Your homepage's visible content changed noticeably since the last time we confirmed it looked normal. Often this is completely expected — a new blog post, an updated review section, a seasonal promotion. We're more lenient when new content is simply added without touching what was already there, and stricter when existing content is replaced or removed, since that pattern is more consistent with a defacement or an injected redirect than routine site activity. If you made the change yourself, no action is needed.

The email address(es) or phone number(s) on your watched contact page changed since we last confirmed things looked normal. By default that's your homepage, but you can point it at a different page in Site Settings if your real contact info lives elsewhere — useful if, say, your homepage doesn't have it but another page does. This gets flagged on its own, at a higher severity than a general content change, because swapped contact information is a classic sign of a compromised site — attackers often replace a business's real contact details with their own to intercept customers. If you updated this yourself, no action is needed. Site Settings also shows exactly what we're currently watching, and lets you correct it directly if the automatic scan ever picks up the wrong thing.

Open is the default for anything new — it hasn't been looked at yet. Under review means someone on your team is looking into it. Resolved means it's been handled. Marking something resolved doesn't delete it — it stays in your findings history, it just stops counting against the site's "needs attention" indicator. You can reopen anything at any time if it turns out the problem wasn't actually fixed.

If you think a specific finding is wrong — a false positive, or something that doesn't match what you're actually seeing on your site — this opens a real support ticket straight to our team with the details of that finding already included, so we can take a look and follow up with you directly.

Yes. In each site's Settings, the account owner and every teammate can independently turn notifications for that site on or off for themselves. You can also turn off entire categories of finding on a per-site basis — useful if, say, your site changes content often enough that content-change alerts aren't useful to you.

Findings — the actual history of everything we've ever caught — are kept indefinitely and never deleted. Trend charts (uptime %, response time, PageSpeed score over time) keep up to 12 months of history to stay fast and manageable; anything older is archived, not simply thrown away. If you ever need data from further back than what's shown, contact support and we'll help.