Website monitoring for small business.One watcher for uptime, SSL, contact forms, broken links, and page speed.

Uptime is the foundational check — the one that earns its keep the loudest the first time it fires. A 502, a host suspension, a DNS record that drifted off the apex after a registrar migration, a CDN edge going dark during a scheduled rotation — every one of these shows up identically at the probe edge: the HTTP request timed out, or it returned a 5xx, or it never resolved. The probe does not care why. It just knows the site is not answering.

For a small business, the cost of an undetected outage is direct and immediate. A visitor hits the homepage during the two hours the site is down, sees nothing, and does not come back. Without a probe running from outside, the founder finds out when a customer emails to ask if the business is still open. With a probe, they get an email in the minute the probe fails — and a second short email when the site comes back up. The cost-lens on a four-hour order-wave outage — what twenty to forty missed orders during the loud order wave actually adds up to, and what shortens the lost-revenue window — is costed out in the dedicated breakdown on the website downtime cost for small business article.

The free uptime check runs the same probe against any URL, on demand, with no signup. The product runs it on a cadence — every five minutes on Starter, every minute on Pro — and alerts the moment the check fails. One URL, one email address, and the monitor watches every refresh in between. That is the entire surface area of uptime monitoring for a small-business site.

An expired SSL certificate is the loudest failure mode a small-business site can have, and the most avoidable. Every visitor who opens the URL after the certificate lapses sees a full-browser red padlock warning — not an error message, not a slow page, but a trust-destroying security alert that makes the site look compromised. Every conversion metric drops to zero while the warning is active, because virtually no visitor clicks through a red padlock to a small-business contact form.

The proximate cause is almost always auto-renew failure: the renewal webhook silently dropped, the hosting account credit card expired, the domain-level certificate override lapsed while the hosting-level one stayed active. None of these failures announce themselves. They accumulate quietly in the background until the certificate window closes, and by then every visitor is seeing the warning.

The right monitor checks the certificate days before the renewal window opens — at fourteen days remaining the alert fires, the operator forwards it to the host, the renewal goes through. The blast radius is contained before it starts. The free SSL checker runs the same check against any URL, reports the issuer, the chain, and the renewal window, and tells you what a browser would show right now.

A small-business site accumulates broken outbound links the same way it accumulates anything else nobody is actively watching: slowly, then all at once. A partner reference moves to a new domain, the external blog post the FAQ cites gets deleted, the vendor page it links to redirects to a new slug and then 404s again six months later. None of these failures alert anyone. They sit in the HTML, accumulating, until a crawler walks them.

The SEO impact is real. Google documents that crawlable links contribute to the trust signal the page sends. A link that resolves to a 404 does not send a trust signal — it sends a broken one. For a small-business contact or landing page, where every element of the page is working to build the visitor’s confidence, a broken outbound link in the resource section or the FAQ is the wrong note at the wrong moment.

The free broken-link scanner crawls a page or a sitemap and surfaces every 404, redirect loop, and dead anchor it finds — the same check that fires the alert in the product version. Run it now on the pages that matter most: the contact page, the homepage, the FAQ. The failures are usually cheap to fix; the cost is in not knowing they’re there.

A contact form that silently drops submissions is the most expensive failure mode a small-business site can have — more expensive, in practice, than a fully-down homepage. When the homepage is down, the visitor knows the site is broken. When the contact form silently fails, the visitor believes the message was sent. They wait for a reply that never arrives, assume the business is unresponsive, and go elsewhere. The business never finds out the submission was lost.

The failure is common. A transactional email provider quota runs out. An SPF record change breaks the sending domain authentication. A PHP mail() function on shared hosting starts silently rejecting. A form plugin updates and the webhook destination stops accepting POST requests. In each case, the form returns HTTP 200, the browser renders the thank-you message, and the lead is gone. First-inspection failure rates run from 10% to 30% across mid-size small-business sites.

The monitoring surface for this problem is a probe that submits a test submission against the form on a schedule, then confirms the submission reaches the destination inbox. When the submission does not arrive, the alert fires. The product version runs this on the cadence you set. The free contact-form monitoring page explains what the probe checks, what it catches, and how to wire it to the inbox that matters.

A checkout page that returns HTTP 200 but does not complete the transaction is the worst kind of failure in the entire monitoring surface. The customer believes they paid. The cart empties. The /thank-you renders. The merchant never sees the order — because the payment provider returned a non-success status while the storefront template completed anyway, or because the payment redirect silently failed halfway through, or because a plugin update broke the order-creation hook on a Tuesday morning.

For a small business that runs on a handful of daily transactions, a checkout failure that goes undetected for six hours is not a monitoring edge case. It is the scenario where the annual subscription pays for itself in a single incident. The probe has to reach /checkout, confirm the page renders the first input, confirm the payment redirect is reachable, and confirm the merchant dashboard reflects the order. Not just that the URL answered.

Checkout failure monitoring is the deep-dive leaf for this failure shape: what the probe checks, where the payment-redirect risk sits, and how to wire the alert into a one-person operation that is never on call. It covers the failure modes that standard uptime monitoring misses — the ones that only surface when someone actually tries to buy something.