Let's Encrypt shut down OCSP entirely in August 2025. Chrome and Firefox both moved revocation checking off the live connection years ago. Most OCSP stapling tutorials still teach it as the default, without saying any of that.
Most guides say removal "takes months." The real number, from the official removal page, is 6 to 12 weeks to reach most Chrome users, and Firefox and Safari run their own separate clocks entirely.
503 means a server is deliberately not serving right now. 504 means something upstream never answered in time. The trigger conditions for each are different in nginx, AWS ALB, and Cloudflare, and none of them share the same defaults.
Let's Encrypt's shift to 45-day certificates will double daily renewal requests. Here is which rate limit you actually hit, why, how long until it resets, and the one mechanism most automated setups already have that sidesteps the problem entirely.
A real CNAME can never sit at a zone apex, so every provider invented its own workaround: ALIAS, ANAME, CNAME flattening. Three names for roughly the same trick, with real differences in TTL handling and DNSSEC behavior, plus a newer standards-based alternative most guides skip.
Five directives, one table, and four ways getting one of them wrong actually breaks a site: a personal page cached on a shared CDN, a logged-out user seeing a previous session on the back button, and two more.
A check run from one location can fail for reasons that have nothing to do with your site, including, in one real 2025 incident, a problem with the monitoring vendor's own infrastructure in that region. Here is what actually causes this, and what confirming from elsewhere buys you.
DNSSEC fails closed: a broken chain of trust returns SERVFAIL, not a wrong answer. Two real incidents, Slack in 2021 and a TLD-wide DENIC outage in 2026, show the two root causes that actually happen, and the fast path to telling them apart.
Six headers cover most of the real risk, and the free scanner every checklist points you to recently lost its API. Here is what actually matters, what to skip, and how to verify it without depending on a one-off manual scan.
Most SSL monitoring dashboards show a green check for two things: the TLS handshake succeeded and the certificate has not expired. Neither one confirms the chain is complete, and an incomplete chain fails silently for exactly the clients your monitor never tests.
Most SEO monitoring advice means stitching together five separate tools and a dashboard yourself. The signals that actually predict a traffic drop, robots.txt, canonical, hreflang, noindex, sitemap coverage, and link health, are more useful correlated in one place than tracked apart.
Every subdomain takeover guide is written for a security team hunting exposure. Most takeovers start as an ops mistake: a CNAME left behind after a vendor migration or a decommissioned SaaS tool, with nobody deleting the record.
Every incident management guide assumes you will build your own severity matrix, even the ones that call it automated. A monitoring tool that assigns severity by what actually happened does not need one at all, at least not for the incidents it already knows about.
For programmatic incident consumption, webhooks deliver in about a second. Polling adds an average of half your poll interval on top, pure waiting, after the incident already exists. Here is the real tradeoff, and the failure mode most guides skip.
RDAP rate limits vary wildly by registry, from 10 requests per 10 seconds to 300 a day, none of it standardized. Real per-registry numbers and what ICANN's RDRS access-tier system actually is in 2026.
DNS propagation isn't a transport mechanism, it's cache expiry. Negative caching, not TTL alone, explains why a fresh record can lag. Here's how to actually verify a change, and why that verification never really stops.
An RDAP JSON response reads in four groups: identity, events, entities, and status, plus a few blocks you can skip. Walked through with one real response for example.com, field by field, in the order you actually need them.
A monitor that says your site is down is not always right. Cloudflare can block your monitoring bot specifically, or have its own outage, and neither one means your server is broken.
Cloudflare’s 521 through 526 errors all mean the same broad thing: Cloudflare reached the internet fine, but something went wrong between Cloudflare and your own server. Here is what each code means, and what actually catches each one.
A sitemap is a snapshot of what your site looked like when it was generated. A crawl reflects your site right now. The two drift apart continuously, not just after a big migration.
A weekly link crawl catches most broken links before they cost you traffic. When you find them, internal 404s on your highest-traffic pages come first, then redirect chains, then outbound links last.
WHOIS and RDAP look up the same domain registration record, but only one of them is still the protocol ICANN actually requires. Here is the real difference and the verified 2019 to 2025 timeline that made RDAP the default.
Building a certificate inventory from scratch is unnecessary work. Certificate Transparency logs already record every certificate issued for your domain, in public, for free. Here is how to read that record yourself.
Let's Encrypt ended its certificate expiration emails in June 2025. Here is why its own recommended fix does not solve the real problem, and what actually catches a renewal that fails silently.
Domain monitoring and DNS monitoring watch two different layers of the same name: registration versus resolution. Here is what each one catches, where they overlap at the nameserver, and which layer catches which outage, so you know why you need both.
Domain hijacking shows up in the registration record before you lose the name: a transfer lock removed, a pendingTransfer flag, a nameserver or registrant rewrite. Here is how to detect domain hijacking early by watching WHOIS and RDAP, with the perl.com case as the lesson.
Domain expiry monitoring reads your domain's WHOIS or RDAP record on a schedule and warns you weeks ahead, so a missed renewal never takes your site, email, and certificates offline at the same time. Here is the expiry lifecycle, how to check it, and how to alert in time.
Detecting DNS record changes is a snapshot-and-diff loop on top of dig and the SOA serial. The hard part is not the detection, it is filtering the false positives from GeoDNS, round-robin, and CDN IP rotation so you only alert on changes that matter.
DNS monitoring catches the silent failures an uptime check never shows: records pointing at the wrong server, nameservers out of sync, expired DNSSEC signatures, broken email records. Here is exactly what it catches, what it cannot, and how to start with dig.
Checking an SSL certificate's expiration takes ten seconds with a browser or openssl. The real problem: certificate lifespans have already dropped to 200 days and reach 47 by 2029, so a once-a-year manual check no longer protects you. Here is how to check, and how to automate it.
The famous downtime cost numbers (Gartner's $5,600/min, IDC's $1M/hour) come from enterprise IT surveys that rarely apply to most sites. Here is where each one comes from, why it overstates the cost for most businesses, and a calculation framework that does apply.
Picking an uptime check interval is not a question of "as fast as your plan allows." It is a question of which failure mode you are catching and how fast the world needs to know it is broken. Here is how to pick by impact, plus the alert latency math vendors rarely show.