Site Monitoring and Alerts: Uptime, Certificates, Forms, and Crawler Anomalies

Bottom line first: The typical site incident isn’t that something “breaks”, it’s that it “stays broken for days before anyone notices”. The goal of monitoring is to cut detection time from weeks to minutes: five categories, probe uptime every 1–5 minutes, warn 30 days before a certificate expires, self-test form delivery every 15–60 minutes, watch for week-over-week swings in indexed pages, and verify backup results daily, plus a three-tier P0/P1/P2 alert scheme, all set up in one pass when a new site goes live.

1. Detection Time Determines the Scale of the Loss

First, the boundaries:Monthly Maintenance covers the fixed monthly tasks,Backup Drills covers whether backups can actually be restored,Indexing Diagnostics covers how to troubleshoot indexing anomalies. This guide addresses one prior question: where does the evidence that triggers these actions come from? Without monitoring, maintenance is guesswork; with monitoring, alerts point to a specific failure.

Most incidents on a corporate site aren’t catastrophic, they’re chronic: an expired certificate takes the whole site down, a form fails silently for a week, indexed pages quietly halve. Here’s what each one costs.

Incident	Typical detection time without monitoring	Detection time with monitoring	Direct consequence
Expired certificate	1–7 days	Warning 30 days before expiry	Site unreachable, customers lost
Form fails silently	3–14 days	Alert after 2 consecutive self-test failures	Every inquiry lost, with no one the wiser
Site infected with malware	Weeks	Alerts on indexing and content anomalies	Branded search results polluted
Indexed pages drop sharply	1–2 months	Alert when week-over-week change exceeds threshold	Traffic keeps falling with no one on it
Host goes down	Hours to days	Alert after 2 consecutive failed probes	Inquiries stop

In one sentence: what you buy with monitoring isn’t software, it’s detection time. Cut it from weeks to minutes and inquiry losses go from “the whole batch” to “a few missed”, that’s the entire point.

2. The Five Monitoring Categories and Their Thresholds

These five categories cover every critical path on a B2B website, and the thresholds can be copied as-is.

Category	What’s monitored	Recommended frequency and threshold	Alert condition
Uptime	HTTP status and response time	Probe every 1–5 minutes from at least 2 external nodes	2 consecutive failures; response time over 5 seconds 3 times in a row
Certificates and domains	SSL validity, domain expiry, DNS records	Check daily, escalating warnings at 30/14/7 days before expiry	Less than 30 days to expiry; DNS record changes
Forms and email	Delivery path self-test, bounces	Submit a self-test every 15–60 minutes	2 consecutive self-test submissions not received; bounce rate above 2%
Crawlers and indexing	Key URL crawl status, indexed pages	Check indexing and sitemap errors once a week	Indexed pages drop more than 20% week over week; new sitemap errors appear
Backups and updates	Backup job results, post-update smoke test	Check backups daily; check for blank pages within 1 hour of a component update	Backup fails; homepage or form page returns an error after an update

This table is the heart of the whole guide; the sections that follow break down the configuration details. The test for whether your setup is complete is simple: go through this table line by line and ask “who’s watching, how often, and who gets notified when something breaks.” If you can’t answer all three for a row, that row isn’t configured.

3. Configuration details for uptime and certificate domains

The easiest things to get wrong in uptime monitoring are probe location and alert conditions.

Setting	Recommended practice	Common mistake
Probe nodes	At least 2 external nodes in different regions (e.g. one overseas, one domestic)	Probe on the same machine as the monitored site, so it goes silent along with the site
Probe paths	Homepage plus one form page and one core product page	Testing only the homepage, so CDN caching hides failures on inner pages
Condition	Alert after 2 consecutive failures, response time threshold 5 seconds	Alert on a single failure, so network blips set off alarms every day
Probe interval	1–5 minutes; 1 minute for critical sites	Once every 30 minutes, so you hear about an outage an hour later

The certificate and domain schedule is the least effort and the most certain payoff in this whole guide, because it gives you advance notice instead of an alert after the fact.

Checklist	When to warn	Action
SSL certificate validity	Alert once each at 30, 14, and 7 days before expiry	Check that the auto-renewal job is running (Let’s Encrypt certificates renew every 90 days)
Domain expiry	Remind once each at 60 and 30 days before expiry	Confirm the registrar account and payment method are valid, and turn on auto-renew
DNS record changes	Alert on any change	Investigate unplanned A record or MX record changes immediately

DNS change alerts are often skipped, but they’re exactly the first sign of domain hijacking: the DNS records get pointed elsewhere, the site itself looks fine, and the traffic goes to someone else. This one costs almost nothing per day and is worth setting up.

4. Form emails and crawler indexing

Form monitoring isn’t about whether the page loads, but whether the submission actually arrives. A page that works while the delivery chain is broken is the most hidden and most expensive failure a B2B site can have: the customer thinks they sent an inquiry, and you never receive a single one.

Monitoring method	How to do it	Criteria and alerts
Self-test submission	Use a script or third-party tool to submit a test inquiry every 15–60 minutes	Pass if the test inquiry arrives with all fields complete; alert P0 after 2 consecutive failures
Inbox verification	Name the self-test mailbox in a fixed format (e.g. test+timestamp@domain) so it’s easy to filter and check	If it doesn’t arrive on time, the break is at the email layer
Bounce monitoring	Monitor bounce notifications for the sending mailbox	If the bounce rate exceeds 2%, check the SPF, DKIM, and DMARC configuration
Broken links and delivery re-checks	Walk through the real form flow manually once a quarter	Compare against automated self-check results to catch cases where the self-check script itself has stopped working

Crawling and indexing don’t need high-frequency monitoring. Once a week is enough, and you only need to watch three metrics: the crawl status codes for key URLs (homepage, core product pages, inquiry page), the number of crawl errors after sitemap submission, and the week-over-week change in indexed pages. Index counts naturally fluctuate, so a week-over-week drop of under 20% is no cause for alarm. Only a drop over 20% or two consecutive weeks of decline warrants an alert. For detailed troubleshooting of abnormal crawl statuses, see Indexing Diagnostics for the full process. Monitoring’s only job is to deliver the “time to check” signal on schedule. Backup task results just need a daily success/failure check. As for recovery capability itself, that depends on drills, not monitoring.

5. Alert Tiers, Channels, and False-Positive Management

Alerting on everything means alerting on nothing. If your phone buzzes ten times and nobody responds, the eleventh buzz is when a real incident slips through. The point of tiering is to route different severity levels to different channels and different people.

Tier	Test	Channels and Response Requirements
P0	Site unreachable for over 5 minutes; form submission fails twice in a row; signs of a malware injection	Call or message the on-call person directly via phone or IM bot; respond within 30 minutes
P1	Certificate expires in under 14 days; indexed pages drop over 20% week-over-week; response time consistently exceeds 5 seconds	Email plus group notification; handle within 24 hours
P2	Certificate expiry reminder at 30 days; a single backup failure that recovers the next day; slow-moving trend metrics	Include in weekly report; review at the regular meeting

There’s one hard rule for managing false positives: any monitoring item that triggers frequent false alarms for three consecutive months must either have its threshold adjusted or be turned off. There is no third option. Every alert rule must have an assigned owner. A rule that nobody claims when it fires is essentially unconfigured. Common sources of false positives and how to handle them: a single failure caused by network jitter (solved by requiring two consecutive failures to trigger), CDN caching masking internal page failures (add a probe point on the form page), and email providers flagging test emails (whitelist a dedicated test mailbox).

6. On-Call Response and New Site Launch Checklist

What to do when an alert fires needs to be decided before anything happens. The three levels of action progress by time:

Response Level	Trigger	Action	Target Timeframe
Level 1	Single point of failure, quick to recover	Restart the service, roll back the most recent update	Within 15 minutes
Level 2	Level 1 didn’t work or the failure is spreading	Switch to static cached pages to keep the site accessible	Within 1 hour
Level 3	Can’t be fixed in the short term	Stop guessing, post a notice, and escalate to external support	Within 4 hours

On-call scheduling only needs to answer one question: who can handle it in the middle of the night. A B2B site doesn’t need 24-hour human staffing, but P0 alerts must have at least one person who can be woken up at night and has server access. Without that person, no amount of monitoring gets you past “find out the next morning.”

When a new site goes live, monitoring is set up in one pass: five monitors and three recipients, fixed list.

Required at launch	Content
Five monitors	Uptime, certificate and domain, form delivery, indexing weekly report, and backup results, configured to the thresholds in Section 2
Three recipients	P0 on-call, P1 technical lead, P2 day-to-day contact, each with their own channel connected and one real alert drill run

7. Using alert data to drive improvements, and when not to build your own

Monitoring isn’t just firefighting, it’s a detector for where to improve. Do a quarterly review and look at three numbers: total alerts, the share that were real incidents, and the failure types that keep recurring. If real incidents are under 30%, the rules are too noisy and need tightening. If the same failure type shows up twice or more in a quarter, it’s time to upgrade it from “caught by an alert” to “permanently fixed” — for example, if email delivery keeps flapping, switch sending providers instead of leaving that alert in place. This review can be folded into the quarterly version of your monthly maintenance agenda and run as routine.

When you don’t need to build your own also needs saying: most B2B websites have no reason to build a monitoring system. The minimum set from a third-party probe service — uptime, certificate expiry, form delivery — covers the three costliest types of incident at close to zero cost. Build your own only in two cases: your form pipeline is too complex for a third-party probe to test, or compliance requires monitoring data to stay inside your own environment. If you need help setting up this monitoring and alerting to match your site’s current state, you can Contact Us.

FAQ

Do small sites need monitoring too?

Yes, but the minimum set of three is enough: uptime checks (every 5 minutes, alert after 2 consecutive failures), certificate expiry warnings (starting at 30 days), and form delivery self-checks (once an hour). These three cover the costliest types of incident for a corporate site and can be done with free tiers of third-party services. The indexing weekly report and backup verification can run at a lower frequency, and you can fill in all five once inquiry volume picks up.

Are free monitoring tools good enough?

In most cases, yes. Free tiers of third-party probes usually offer 1–5 minute intervals and multi-node checks, which meet the readability thresholds in Section 2. Two limits to watch: free tiers have few nodes, so you’ll get the occasional false alarm from a single node — filter it with a “2 consecutive failures” rule; and free tiers usually only support HTTP checks, so form delivery self-checks need your own script or a paid tier’s scripted check capability. How to decide on budget: if a year of monitoring costs less than one certificate expiry incident, it’s worth paying for.

What do I do when there are so many alerts that people stop paying attention?

Tighten rules by false-positive policy: any rule that fires false alarms at high frequency for three straight months gets its threshold adjusted or is turned off; every rule gets an owner, and rules nobody claims are retired. Then split channels by severity: only P0 goes to instant push alerts, P1 goes to email and group chat, P2 goes to the weekly report only. The bar for calling it done: two straight weeks with zero false positives in the P0 channel, and no real incident missed.

Should a drop in indexed pages trigger an alert?

Yes, but keep the threshold loose. Indexed page counts fluctuate naturally; a week-over-week drop of 20% or less is normal and doesn’t need an alert. Only a drop over 20%, or two consecutive weeks of decline, triggers a P1. Monitoring’s only job is to send the signal that it’s time to look; the actual crawl and index troubleshooting has its own process. Also note that checking indexed pages once a week is enough. Staring at the number daily only creates anxiety, it doesn’t surface real problems any sooner.

How does monitoring relate to monthly maintenance?

Monitoring finds problems, maintenance fixes them. One triggers the other; it doesn’t replace it. Monthly maintenance is a fixed-cadence routine, while monitoring is the around-the-clock sentry between maintenance sessions. A certificate expiring between maintenance days, a form breaking between maintenance days, both get caught because monitoring fires first. In practice, treat monitoring alerts as a standing input to the maintenance meeting: go through what fired last month, what was handled, and what became an open fix item, one by one.

What if an alert fires in the middle of the night and nobody responds?

That means your on-call coverage has a gap. Start by answering who can respond at night: at least one person with server access who can be woken by the P0 channel. If you truly have no one, set up P0 automated actions instead: auto-restart the service, auto-switch to a static cached page. Then write the three-tier response actions into a doc: restart or roll back within 15 minutes, switch to a static page within 1 hour, escalate to outside support within 4 hours. For a site that can’t rely on anyone on short notice, it’s better to loosen the P0 threshold to 10 minutes of continuous failure than to configure an alert that fires and then sits unanswered.

Final thoughts

The whole value of a monitoring system comes down to one formula: loss equals downtime multiplied by loss per unit of time, and monitoring cuts the first term from hours to minutes. Set up all five monitoring categories with the thresholds from section two, wire up the three alert tiers with owners, and tighten false positives every quarter. Do those three things and a site incident drops from disaster to to-do item.

One rule is enough to remember: monitoring doesn’t buy you software, it buys you time to find out. An alert rule nobody owns may as well not exist.