Monitoring your DTC site: alert thresholds for uptime, performance, errors, and certificates
1. Uptime monitoring: check every 5 minutes, only count consecutive failures
Uptime monitoring is the most basic layer: can the site load at all? Many people alert on a single failed check, so one network blip wakes someone up, and within a week everyone has turned alerts off. The right approach is to only act on consecutive failures: two in a row sends a yellow group message, three in a row sends an SMS and phone call. Check every 5 minutes from at least 3 locations worldwide (say US East, Europe, and Asia-Pacific) to avoid false alarms from a single probe.
Don’t monitor only the homepage. The homepage may still be up thanks to caching while a product page or inquiry form is already down. Monitor at least three URLs: the homepage, a product detail page, and the inquiry form submission endpoint. If any one goes down, that counts as an uptime incident. UptimeRobot’s free plan is enough: 50 monitors, 5-minute intervals, and multiple global probe locations.
| Monitor | Probe interval | Yellow threshold | Red threshold | Notification |
|---|---|---|---|---|
| Homepage HTTP status | 5 minutes | 2 consecutive non-200 | 3 consecutive non-200 | Group message → SMS and phone call |
| Product detail page | 5 minutes | 2 consecutive non-200 | 3 consecutive non-200 | Group message → SMS and phone call |
| Inquiry form endpoint | 10 minutes | 2 consecutive 5xx | 3 consecutive 5xx | Group message → SMS and phone call |
| TCP port 22/3306 | 5 minutes | Unreachable | — | Group message (business hours only) |
| SSL certificate | 24 hours | 30 days remaining | 15 days remaining | Email → WeCom |
Example: a cross-border site used UptimeRobot to monitor its homepage, set to alert only after 3 consecutive failures. One night the Singapore probe failed 3 times in a row, but the US East and Europe probes were fine. It was a local network issue in Singapore, not a site outage. With single-check alerts, the on-call person would have been woken at 2 a.m., found the site perfectly fine, and stopped trusting the alerts. Multiple probes plus consecutive failures keep false alarms to a minimum.
Uptime and disaster recovery RTO/RPO go hand in hand: when an uptime alert fires, follow the recovery runbook. For how to tell when a CDN node fails, see CDN global acceleration.
2. Performance monitoring: watch LCP, not the overall score
The biggest mistake in performance monitoring is watching the overall score. Google PageSpeed scores swing wildly — the same page can score 85 in the morning and 65 in the afternoon, and alerting on that noise is pointless. What you should actually watch is the three Core Web Vitals, especially LCP (Largest Contentful Paint), which directly affects how users perceive the page and your SEO rankings.
Don’t alert on a single threshold for performance — alert on duration. An LCP over 2.5 seconds once could just be one user on a bad connection; it’s only a real problem if it lasts more than 10 minutes. Yellow threshold: LCP over 2.5 seconds for 10 minutes. Red threshold: LCP over 4 seconds for 15 minutes. Use tools like BrowserStack SpeedCurve or the public data in the Chrome User Experience Report, and review trends monthly.
| Metrics | Pass line | Yellow threshold | Red threshold | Description |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤2.5s | >2.5s for 10 minutes | >4s for 15 minutes | Most critical; directly affects SEO and conversions |
| INP (Interaction to Next Paint) | ≤ 200ms | >200ms for 10 minutes | >500ms for 15 minutes | Watch for laggy form submissions |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | >0.1 for 10 minutes | >0.25 for 15 minutes | Caused by ads or lazy-loaded images |
| TTFB (Time to First Byte) | ≤600ms | >600ms for 10 minutes | >1.5s for 15 minutes | Slow backend or database issues |
| Site-wide error rate | <1% | >1% for 5 minutes | >5% for 10 minutes | Track 5xx and 4xx separately |
Example: one morning, a site’s LCP jumped from 1.8s to 3.5s and recovered on its own after 20 minutes. The logs showed a slow database query — a plugin’s scheduled task was running a full table scan. Without an alert, any inquiry submitted during those 20 minutes would have timed out, losing the sale outright. That’s the value of performance monitoring: catching this kind of momentary degradation. For how to optimize Core Web Vitals, see Core Web Vitals thresholds and optimization priorities.
3. Error rates and logs: look at 5xx and 4xx separately
Error rate monitoring splits into two categories: 5xx are server errors and must trigger alerts; 4xx are client errors and mostly don’t matter. Mix the two together and you either get too many alerts or the real problems get buried. A 5xx rate over 1% for 5 minutes triggers yellow; over 5% for 10 minutes triggers red. For 4xx, only monitor spikes in 404s — a jump in 404s means broken backlinks or a site update that missed a 301 redirect.
Use a tool like Sentry for error tracking — it automatically collects frontend JS errors and backend exceptions and groups them by error. A standalone site doesn’t need to chase every error, but it should watch how often the top 3 errors occur. If an error suddenly goes from once a week to 10 times an hour, a release introduced a bug. For how to do log analysis, see AI Crawler Log Analysis.
| Error type | Normal baseline | Yellow threshold | Red threshold | What to do |
|---|---|---|---|---|
| 5xx server errors | <0.5% | >1% for 5 minutes | >5% for 10 minutes | Check backend logs; roll back or scale up |
| 404 page not found | <1% | 3x spike for 1 hour | 10x spike | Check backlinks and 301 mappings |
| Frontend JS errors | <10/day | >50/day | >200/day | Triage by Sentry group |
| Inquiry form submission failures | <1% | >3% for 10 minutes | >10% | Check SMTP and CRM sync |
| Database connection failed | 0 times | Once | 3 times in a row | Check MySQL status now |
Example: After a site shipped a new release, a JS error in Sentry jumped from 3 times a day to 200 times a day. Checking the code revealed that a script in an ad slot was throwing an exception on Safari, which blocked form submissions. Without an alert, inquiries from Safari users would be lost. Sentry’s error frequency monitoring can catch this kind of regression within 24 hours of a release.
4. Certificate and backup monitoring: the two things most easily forgotten
Certificate expiration is the most common “rookie mistake” for independent sites. 90% of certificate expirations aren’t a technical problem, they’re a matter of forgetting to renew. Set up two layers of monitoring: email reminder at 30 days remaining, WeCom alert at 15 days remaining. Don’t wait until only 3 days are left, because by then the domain registrar’s email might be going to spam, or DNS resolution issues might be too late to fix. Use UptimeRobot’s certificate monitoring or a custom script to probe daily.
The backup task itself also needs monitoring. If the backup script fails, you won’t know until something goes wrong and you find the last backup was two weeks ago. Three alert rules: alert if the backup task exit code is non-zero; alert if the backup file size drops 30% compared to the previous day (the database might be unreachable); alert if the latest backup is older than 24 hours. For backup strategy details, see Backup and recovery drills for your site.
| Monitor | Check frequency | Yellow threshold | Red threshold | Notification |
|---|---|---|---|---|
| SSL certificate days remaining | Daily | 30 days remaining | 15 days remaining | Email → WeCom |
| Backup task exit code | Every completion | Non-zero | — | WeCom immediately |
| Backup file size | Daily | 30% drop from previous day | 70% drop from previous day | WeCom |
| Backup file age | Daily | >24 hours | >48 hours | WeCom |
| Disk usage | Every hour | >80% | >90% | WeCom |
| CPU/memory | Every 5 minutes | >80% for 10 minutes | >95% for 10 minutes | WeCom |
Counterintuitive reminder: don’t use just one alert channel. Email easily goes to spam, WeCom might be ignored during vacation, SMS and phone calls are the last resort. Important alerts (site down, certificate expiring soon) must go via SMS and phone, while general alerts go to WeCom groups. Also set up an escalation mechanism: if a red alert isn’t handled within 15 minutes, automatically escalate to the technical lead. For the daily inspection checklist, see Six Monthly Tasks for Site Maintenance.
After the monitoring system is set up, review alerts once a month: how many yellow alerts, how many red alerts, and how many were false positives in the past month. Thresholds with a false positive rate over 30% should be tightened or adjusted. The goal of monitoring isn’t to cover every possibility, but to wake someone up the moment something really goes wrong, which means you need to proactively cut the rules that constantly produce false alarms.
FAQ
What tools should independent sites use for monitoring, and are free options enough?
What should we do when the team ignores too many alerts?
How often should uptime monitoring check?
How should we set thresholds for SSL certificate monitoring?
Which performance metric should we watch, and should we track the PageSpeed score?
How do you monitor backup job failures?
Final thoughts
The most common failure in monitoring isn’t a lack of monitoring — it’s too much monitoring that nobody looks at. When you first set it up, you want to watch everything: CPU, memory, disk, network, every URL, every error. A week later there are so many alerts the team goes numb, and the red alert that actually matters drowns in yellow noise. The value of monitoring is waking someone up when it counts, not how much ground it covers.
Three steps to put it into practice. First, set yellow and red thresholds across four dimensions — availability, performance, errors, and certificates. Yellow only posts to the group chat; red triggers SMS and phone calls. Second, run it with a combination of free tools: UptimeRobot plus Sentry plus a certificate script, at a monthly cost of zero. Third, review your alerts once a month and cut any rule with a false positive rate above 30%. Monitoring is a living system, not something you set up once and forget — it needs constant pruning.
One line worth remembering: the goal of monitoring isn’t to cover every possibility — it’s to wake someone up the moment something actually breaks. When alerts pile up until the team mutes them, that’s more dangerous than having no monitoring at all.