The Complete Guide to Website Maintenance and Monitoring

What Is Website Maintenance and Why It Matters

Website maintenance is the ongoing work of keeping a website functional, secure, and performing well. It covers everything from server uptime and certificate renewals to crawlability checks and DNS record hygiene. If you think of launching a website as building a house, maintenance is everything that happens after you move in: fixing leaks, replacing filters, checking the locks.

Most teams treat maintenance as an afterthought. They launch, celebrate, and move on to the next project. Then six months later an SSL certificate expires, a domain lapses, or a DNS record gets silently changed, and suddenly the site is unreachable. According to Gartner, the average cost of IT downtime is $5,600 per minute [1]. For smaller businesses the figure is lower, but the relative impact is often worse because there is no redundancy to fall back on.

Website monitoring is the automated side of website maintenance. Instead of manually checking that everything still works, you configure tools to do it for you and alert you when something breaks. Monitoring does not replace maintenance. It makes maintenance possible at scale by telling you what needs attention before your visitors discover it themselves.

The challenge is that "monitoring" is not one thing. Your website depends on a stack of infrastructure and configuration layers, each of which can fail independently. Your server can be up while your SSL certificate is expired. Your DNS can be correct while your domain registration is about to lapse. A third-party payment processor can go down while your own servers are perfectly healthy. Comprehensive website maintenance means watching all of these layers, not just one.

This guide walks through every monitoring vertical your site needs, explains why each one matters, and points you to dedicated deep-dive guides for each topic. Whether you are managing one site or fifty, the goal is the same: catch problems before they reach your users.

The financial argument for proactive maintenance is well established. A 2024 study by ITIC found that 91% of enterprises report that a single hour of downtime costs over $300,000 [5]. Even for small and mid-sized businesses, the costs are real: lost sales during an outage, degraded search rankings that take weeks to recover, eroded customer trust, and the opportunity cost of the engineering time spent firefighting instead of building. Proactive website maintenance, powered by automated monitoring, is dramatically cheaper than reactive incident response.

The Monitoring Stack: What You Need to Watch

Before diving into each monitoring type, it helps to see the full picture. A production website depends on at least nine distinct layers, and a failure in any one of them can take your site offline or damage its search visibility.

Here is the full monitoring stack:

• Uptime: Is the server responding to requests?
• SSL/TLS certificates: Is the certificate valid, correctly chained, and not about to expire?
• Domain registration: Is the domain renewed and not at risk of lapsing?
• DNS records: Are A, CNAME, MX, and other records correct and unchanged?
• Vendor dependencies: Are the third-party services your site relies on (CDN, payment processor, email provider) operational?
• Redirects: Are your HTTP redirects resolving correctly without chains or loops?
• Sitemaps: Is your XML sitemap valid, up to date, and accessible to search engines?
• robots.txt: Is your robots.txt file correctly configured and not accidentally blocking important content?
• Hreflang: Are your international targeting tags correct and consistent across language versions?

The first five are infrastructure concerns. If any of them fail, your site is broken or unreachable. The last four are technical health concerns. If any of them are misconfigured, search engines will struggle to crawl, index, and rank your content correctly. Both categories require ongoing monitoring because both categories change over time, sometimes without anyone intending them to.

Most teams cobble together a patchwork of free tools and manual spot checks to cover this stack. That works until it does not. The sections below explain each layer in detail and link to dedicated guides where you can go deeper.

Uptime Monitoring

Uptime monitoring is the most fundamental type of website monitoring. It answers the simplest question: can someone actually reach your site right now?

An uptime monitor sends HTTP or HTTPS requests to your URLs at regular intervals, typically every 30 to 60 seconds, from multiple geographic locations. If the server does not respond, returns an error status code, or takes too long, the monitor marks it as a failure and sends you an alert. Most tools require two or three consecutive failures before alerting to filter out transient network blips.

The reason uptime monitoring matters is obvious, but the reasons sites go down are more varied than most people expect. Hardware failures, software crashes, misconfigurations during deployments, hosting provider outages, traffic spikes, and even expired payment methods on hosting accounts can all cause downtime. You cannot prevent every outage, but you can detect them in seconds rather than hours. The difference between a two-minute outage and a two-hour outage is often just whether you had monitoring in place.

Beyond simple "is it up" checks, good uptime monitoring includes response time tracking, content validation (checking that the page actually contains expected text, not just a 200 status code), and multi-location checks that distinguish between a global outage and a regional routing issue. If your site serves customers worldwide, a monitor running from a single data center in Virginia will miss problems affecting users in Europe or Asia.

For an e-commerce site, uptime monitoring should cover not just the homepage but also the checkout flow, the product API, and any payment confirmation pages. A cached homepage can stay up while the application server behind it is completely down. Monitor what matters to revenue, not just what is easiest to check. For a deeper look at how to set up uptime monitoring, configure alert thresholds, and interpret response time data, read the complete uptime monitoring guide.

If you are unsure whether your site is currently down or just slow for you, our guide on how to check if a website is down covers the practical steps. For background on what causes outages in the first place, see website downtime causes and prevention.

SSL Certificate Monitoring

An expired or misconfigured SSL certificate does not just trigger a browser warning. It blocks visitors entirely. Modern browsers like Chrome and Firefox display a full-page interstitial that actively discourages users from proceeding, and most will not. For all practical purposes, an expired SSL certificate is equivalent to your site being completely offline.

SSL certificate monitoring tracks the expiration date of your certificates and validates the full certificate chain on an ongoing basis. A typical setup alerts you at 30 days, 14 days, and 7 days before expiration, giving you escalating urgency to act. But expiration is only one failure mode. Missing intermediate certificates, mismatched hostnames, revoked certificates, and protocol misconfigurations can all break HTTPS connectivity without the certificate technically being expired.

If you use Let's Encrypt with automated renewal (and most sites should), you might assume certificate monitoring is unnecessary. It is not. Auto-renewal fails more often than people realize. A changed server configuration, a full disk, a permissions issue, or a firewall rule blocking the ACME challenge can all prevent renewal silently. You will not know it failed until the certificate actually expires, unless you are monitoring it. For sites using paid certificates with annual renewals, the risk is even higher because the renewal process is manual and easy to forget.

Certificate chain issues are particularly insidious. Your site might load perfectly in Chrome on your desktop while failing completely on mobile Safari or in API clients. This happens when the intermediate certificate is missing from your server configuration but your desktop browser has it cached from a previous visit. Only a monitoring tool that validates the full chain from a clean environment will catch this.

For the full technical breakdown of SSL/TLS monitoring, including how certificate chains work, common misconfiguration patterns, and how to test your setup, read the complete SSL/TLS guide.

Domain Expiry Monitoring

Domain expiry is one of the most overlooked risks in website maintenance. If your domain registration lapses, your entire online presence disappears. Every page, every backlink, every email address associated with that domain stops working. And unlike a server outage that you can fix in minutes, recovering a lapsed domain can take weeks or become impossible if someone else registers it.

Domain expiry monitoring queries WHOIS and RDAP data to track when your domain registration expires and alerts you in advance. Most domain registrars offer auto-renewal, and most of the time it works. But auto-renewal depends on a valid payment method, a reachable administrative email address, and the registrar's own systems functioning correctly. Credit cards expire. Corporate email addresses change when employees leave. Registrars change their policies or billing systems. Any of these can cause auto-renewal to fail silently.

The risk is amplified for organizations that manage multiple domains. An agency managing 30 client sites across three different registrars has 30 potential points of failure. A SaaS company with a primary domain, a marketing domain, a documentation domain, and several country-code domains has the same problem. One missed renewal in the portfolio is enough to cause a serious incident.

Domain squatters and automated bots actively watch for lapsing domains, especially domains with established backlink profiles and traffic. If your domain enters the redemption period, recovering it becomes expensive. If it drops completely, someone else can register it within hours and there is very little you can do about it. The only reliable defense is knowing well in advance that a domain is approaching its expiration date.

For a detailed guide on domain expiry risks, how registrar grace periods work, and how to set up monitoring for your entire domain portfolio, read the complete domain expiry guide.

DNS Monitoring

DNS is the layer that translates your domain name into the IP address where your site is hosted. If your DNS records are wrong, visitors cannot reach your site, even if the server is running perfectly. DNS monitoring watches your records for changes and alerts you when something shifts.

There are several scenarios where DNS records change unexpectedly. A team member makes an accidental edit in the DNS management panel. A migration to a new hosting provider introduces a typo in an A record. A compromised DNS account leads to malicious record changes that redirect your traffic to an attacker's server. A provider changes their nameserver IPs without adequate notice. In all of these cases, the change propagates across the global DNS system within hours, and the impact can range from a partial outage to a complete hijacking of your web traffic and email.

DNS monitoring works by periodically resolving your records and comparing the results against a known-good baseline. When a record changes, you get alerted. This covers A records (where your site is hosted), CNAME records (aliases), MX records (email routing), TXT records (SPF, DKIM, and verification entries), and NS records (which nameservers are authoritative for your domain). A change to any of these can have serious consequences. A modified MX record can silently redirect your email to an attacker. A deleted TXT record can break your email authentication and cause legitimate mail to land in spam.

DNS propagation adds another layer of complexity. When you intentionally change a DNS record, the change does not take effect everywhere simultaneously. It propagates across nameservers worldwide over a period of minutes to hours depending on TTL values. Monitoring from multiple locations helps you verify that an intended change has fully propagated, and that unintended changes are caught regardless of where they appear first.

For the full guide on DNS record types, propagation mechanics, and how to set up DNS change monitoring, read the complete DNS guide. For a primer on propagation specifically, see our article on DNS propagation explained.

Vendor and Service Status Monitoring

Your website does not run in isolation. It depends on a chain of third-party services: CDNs like Cloudflare or AWS CloudFront, payment processors like Stripe or PayPal, email delivery services like SendGrid or Mailgun, analytics platforms, authentication providers, CMS backends, and dozens of other SaaS tools. When any of these go down, parts of your site break, even if your own servers are perfectly healthy.

Vendor monitoring tracks the operational status of the third-party services your site depends on. This typically works by polling public status pages, monitoring API endpoints, and aggregating reports from multiple sources. When a vendor reports a degradation or outage, you get alerted so you can assess the impact on your site and communicate proactively with your users.

The problem with relying solely on vendor status pages is that they are often slow to update. A payment processor might be failing for 20 minutes before their status page reflects an incident. Some vendors are notoriously optimistic about their status reporting. Effective vendor monitoring combines status page polling with independent health checks (hitting the vendor's API directly) to detect issues faster than the vendor's own reporting.

The practical impact of vendor outages is significant. If Stripe goes down, your checkout is broken. If Cloudflare has a routing issue, your CDN-fronted assets disappear. If your email provider is degraded, password reset emails and order confirmations are not delivered. In each case, your users blame you, not your vendor. Knowing about these outages in real time lets you display maintenance notices, switch to fallback services, or at minimum set correct expectations with your support team.

For a detailed guide on mapping your vendor dependencies, setting up status monitoring, and building vendor outage playbooks, read the complete vendor monitoring guide.

Technical Health: Redirect Monitoring

HTTP redirects are a routine part of web infrastructure. You use them when you move content to a new URL, consolidate duplicate pages, enforce HTTPS, redirect www to non-www (or vice versa), and handle domain migrations. A single redirect is harmless. A broken redirect, a redirect chain, or a redirect loop is a problem.

Redirect chains occur when one redirect points to another redirect, which points to another, and so on. Each hop adds latency, and search engines have limited patience for following chains. Google will follow up to about five hops before giving up, meaning content at the end of a long chain may never get indexed [2]. Redirect loops, where A redirects to B and B redirects back to A, make the target URL completely unreachable and trigger browser error pages.

These issues tend to accumulate over time. A site migration creates a batch of redirects. A year later, another migration redirects some of those target URLs to new locations, creating two-hop chains. Another round of changes adds a third hop. Nobody audits the redirect map because it is invisible to casual browsing. The technical debt compounds silently until it affects crawling, indexing, and page speed.

Redirect monitoring checks your redirect paths to verify they resolve correctly, measures the number of hops, detects loops, and flags chains that should be consolidated. Running these checks regularly catches problems introduced by CMS updates, plugin changes, and manual URL adjustments before they affect your search performance.

For a thorough guide on redirect types, status codes, chain diagnosis, and best practices for clean redirect architecture, read the complete HTTP redirect guide. For specific guidance on the difference between 301 and 302 redirects, see our 301 vs 302 redirect comparison.

Technical Health: Sitemap Monitoring

An XML sitemap is a file that lists the URLs on your site that you want search engines to crawl and index. It acts as a roadmap for crawlers, helping them discover pages they might miss through link-following alone. For large sites, sites with deep navigation structures, or sites that publish frequently, a well-maintained sitemap is essential for search visibility.

Sitemaps can break in several ways. A CMS update might generate a sitemap with invalid XML syntax, making the entire file unreadable to parsers. URLs in the sitemap might point to pages that return 404 errors. The sitemap might not include newly published pages because the generation process is cached or misconfigured. The file might grow beyond the 50MB or 50,000 URL limits defined in the sitemaps protocol [3]. Any of these issues means search engines are not getting the information they need to crawl your site effectively.

Sitemap monitoring validates your sitemap files on a recurring basis. It checks XML syntax, verifies that listed URLs are accessible, flags URLs that return error status codes, and confirms that the sitemap size and URL count are within protocol limits. For sites with sitemap index files (a sitemap of sitemaps), monitoring should validate both the index and the individual sitemaps it references.

The practical benefit is straightforward. If Google cannot read your sitemap, it relies entirely on link discovery to find your pages. For a blog with 500 posts, that might be fine. For an e-commerce site with 50,000 product pages that change frequently, a broken sitemap means new products and updated prices are crawled slower or not at all.

For a comprehensive guide on XML sitemap structure, generation tools, validation, and submission to search engines, read the complete XML sitemap guide. You can also review our articles on sitemap best practices and how to find your sitemap.

Technical Health: robots.txt Monitoring

Your robots.txt file controls which parts of your site search engine crawlers are allowed to access. It is a small text file with outsized impact. A single misconfigured line can block Google from crawling your entire site, effectively de-indexing you from search results.

The most common robots.txt disasters are self-inflicted. A developer adds Disallow: / during staging to prevent search engines from indexing a test environment, then the staging robots.txt file gets deployed to production. A CMS plugin updates the robots.txt and inadvertently blocks a critical directory. An overly broad disallow rule meant to block one admin path ends up blocking all paths that share a prefix. These mistakes are easy to make and hard to notice because your site continues to work perfectly for human visitors. Only search engine crawlers are affected, and the impact takes days or weeks to become visible in search rankings.

robots.txt monitoring checks your file on a recurring basis to ensure it has not changed unexpectedly and that the rules it contains match your intentions. Good monitoring tools parse the directives and flag rules that would block known-important URL patterns, alert you when the file changes, and verify that the file is accessible (a 5xx error on robots.txt can cause some crawlers to treat your entire site as blocked).

Beyond accidental misconfiguration, robots.txt is increasingly relevant for managing AI crawler access. Companies like OpenAI, Anthropic, and Google use web crawlers to collect training data, and robots.txt is the primary mechanism for opting out. Monitoring your robots.txt ensures that your AI crawler directives remain in place and have not been overwritten by a CMS update or deployment.

For the full guide on robots.txt syntax, directive priority, common mistakes, and testing tools, read the complete robots.txt guide. For specific guidance on blocking AI crawlers, see our article on blocking AI crawlers with robots.txt.

Technical Health: Hreflang Monitoring

Hreflang tags tell search engines which language and regional version of a page to serve to which users. If your site is available in English, French, and German, hreflang tags ensure that French-speaking users in France see the French version in search results, not the English one. For any site targeting multiple languages or regions, correct hreflang implementation is critical for international SEO.

Hreflang is also one of the most error-prone technical SEO implementations. Google's John Mueller has called it "one of the most complex aspects of SEO" [4], and the data backs this up. Common errors include missing return tags (if page A points to page B as an alternate, page B must point back to page A), incorrect language or region codes, hreflang tags pointing to non-canonical URLs, and missing x-default annotations. These errors can cause search engines to ignore your hreflang markup entirely, resulting in the wrong language version ranking in the wrong country.

The complexity scales with the number of language versions. A site with two languages has a manageable hreflang map. A site with 15 languages and 5 regional variants has a combinatorial explosion of tags that must all be consistent and reciprocal. CMS updates, page deletions, URL changes, and content launches can all break hreflang consistency without anyone noticing.

Hreflang monitoring validates your tags across all language versions, checks for return tag consistency, verifies language and region codes against ISO standards, and flags references to non-existent or non-canonical URLs. Running these checks on a schedule catches hreflang regressions introduced by content changes before they affect your international search visibility.

For the complete guide on hreflang syntax, implementation methods (HTML tags, HTTP headers, and sitemap annotations), common errors, and validation workflows, read the complete hreflang guide. For a quick reference on common hreflang errors and how to fix them, see our hreflang errors and fixes article.

Website Security Monitoring

Security is a cross-cutting concern that touches every layer of the monitoring stack. It is not a separate vertical so much as a lens you apply to everything else. An expired SSL certificate is a security issue. A hijacked DNS record is a security issue. A modified robots.txt that exposes a previously hidden admin directory is a security issue.

Website security monitoring adds a security-specific perspective to your existing checks. This includes scanning for malware injections, checking that security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security) are present and correctly configured, verifying that your site is not appearing on blocklists, and confirming that HTTPS is enforced across all pages without mixed content warnings.

The connection between security and the other monitoring types is direct. SSL monitoring catches certificate issues that create encryption vulnerabilities. DNS monitoring catches record changes that could indicate domain hijacking. Vendor monitoring alerts you when a third-party JavaScript provider is compromised, which can cascade into a supply-chain attack on your site. Redirect monitoring catches injected redirects that send your visitors to malicious destinations.

Security monitoring also includes keeping an eye on your site's presence on public blocklists maintained by services like Google Safe Browsing and PhishTank. If your site ends up on one of these lists, browsers will warn visitors away with full-screen interstitial pages. This can happen if your site is compromised and used to host phishing content, or even if a third-party resource loaded on your pages gets flagged. Regular blocklist checking ensures you catch these listings quickly and begin the remediation and delisting process before the traffic impact compounds.

For a focused guide on website security monitoring practices, see our website security monitoring guide. For practical steps on assessing your site's safety posture, see how to check website safety.

Incident Response and Communication

Monitoring is only useful if you can act on it. When an alert fires at 2 AM, the question is not "do we know about it?" but "do we know what to do about it?"

An incident response plan defines who gets alerted, how they triage the issue, what escalation paths exist, and how you communicate with affected users. Without a plan, every incident becomes an improvised fire drill where the first person to notice the alert tries to figure out what is wrong, who can fix it, and whether anyone has already started working on it.

Good incident response starts with clear ownership. Every monitoring alert should have a defined responder or team. Uptime alerts might go to the engineering on-call rotation. SSL and domain expiry alerts might go to the DevOps team. Vendor outage alerts might go to the support team so they can prepare for incoming tickets. Hreflang and sitemap issues might go to the SEO team. If an alert goes to "everyone," it effectively goes to no one.

Communication during an incident is equally important. Your users will find out about an outage whether you tell them or not. Proactive communication, even a simple status page update saying "we are aware of the issue and investigating," builds trust. Silence erodes it. Many teams use a public status page that integrates with their monitoring tools, automatically reflecting incidents as they are detected and resolved.

Post-incident review closes the loop. After every significant incident, document what happened, when it was detected, how it was resolved, and what changes would prevent or reduce the impact of a similar incident in the future. These reviews are where monitoring improvements come from. If an SSL expiry caused an outage because the alert was going to a former employee's email, the fix is not just renewing the certificate but updating the alert routing.

The connection between monitoring and incident response should be tight. Your monitoring tools should feed directly into your incident management workflow, whether that is a Slack channel, a PagerDuty rotation, or a simple email escalation chain. The fewer manual steps between "alert fires" and "someone is working on it," the shorter your mean time to resolution. Teams that treat monitoring and incident response as separate concerns inevitably end up with alerts that nobody acts on, which is worse than having no monitoring at all because it creates a false sense of security.

For a ready-to-use framework including escalation templates and communication checklists, see our incident response plan template.

Building a Website Maintenance Monitoring Checklist

With nine monitoring verticals to cover, it helps to have a structured checklist you can work through systematically. Here is a high-level framework for building yours.

Inventory Your Assets

Start by listing everything that needs monitoring. This includes all domains and subdomains, SSL certificates (including wildcards and certificates managed by CDNs), DNS zones, critical third-party services, redirect rules, sitemaps, robots.txt files, and hreflang implementations. You cannot monitor what you have not inventoried.

Prioritize by Impact

Not every monitoring type is equally urgent for every site. A single-language blog does not need hreflang monitoring. A site that does not use redirects does not need redirect chain checking. But every site needs uptime, SSL, and domain expiry monitoring. Start with the highest-impact items and expand coverage over time.

Set Alert Thresholds

For each monitoring type, define what constitutes a problem and how urgently it needs attention. An uptime failure needs a response in minutes. A certificate expiring in 30 days needs attention this week. A sitemap validation error needs investigation within a few days. Set thresholds that match the urgency.

Assign Ownership

Every alert type needs a clear owner. Map each monitoring category to a person or team, with a backup for when the primary owner is unavailable. Document this mapping somewhere accessible, not buried in a monitoring tool's configuration.

Test Your Alerts

Set up monitoring and then intentionally trigger a test alert for each channel (email, Slack, SMS, webhook). Verify that the right people receive it and that the alert contains enough context to begin troubleshooting. An alert that says "check failed" without specifying what check, what URL, or what the error was is nearly useless at 3 AM.

For a detailed, item-by-item checklist covering every monitoring category, see our website monitoring checklist.

The Case for Unified Monitoring

At this point you might be thinking: that is a lot of monitoring. Nine verticals, multiple tools, different dashboards, separate alert configurations. Can I just cobble together free tools for each one?

You can. Many teams do. And it works, right up until it does not.

The problem with using separate tools for each monitoring type is operational overhead. You are managing nine logins, nine notification configurations, nine sets of credentials, and nine different interfaces for checking status. When an incident spans multiple layers (a DNS change that also breaks SSL, for example), you are switching between tools trying to correlate what happened. Alert fatigue sets in because each tool has its own notification logic and there is no way to deduplicate or correlate across them.

There is also the coverage gap problem. When monitoring is spread across multiple tools, nobody has a clear picture of what is monitored and what is not. The uptime tool covers the primary domain but not the subdomains. The SSL monitor covers the main site but not the CDN certificate. The DNS monitor was set up by someone who left the team and nobody knows the login. These gaps accumulate silently.

Unified monitoring solves both problems. A single dashboard that covers uptime, SSL, domain expiry, DNS, vendor status, redirects, sitemaps, robots.txt, and hreflang gives you one place to check, one alert pipeline to configure, one credential to manage, and one view that shows the complete health of your web presence. When an incident crosses monitoring types, the correlation is immediate because all the data is in the same system.

The cost argument favors unified monitoring too. Nine separate tools, even at entry-level pricing, add up. A typical monitoring stack might include an uptime monitor ($10-30/month), an SSL checker (free but manual), a domain expiry service ($5-10/month per domain), and so on. The cumulative cost in dollars and management time exceeds what a single unified tool charges. And the free tools often come with limitations (check frequency, alert channels, history retention) that make them inadequate for production use.

This is the problem Site Watcher was built to solve. Instead of stitching together nine different services, you get one dashboard that monitors all nine verticals. Flat pricing, no per-check fees, no juggling credentials across providers. Every monitoring type described in this guide is covered from a single interface with unified alerting and a consolidated status view.

There is also a knowledge continuity benefit. When one person sets up nine different tools and then leaves the company, their successor inherits nine different configurations with nine different sets of documentation (or, more likely, no documentation at all). A unified tool means there is one system to learn, one configuration to audit, and one set of historical data that stays consistent regardless of team changes.

For teams managing multiple websites, unified monitoring becomes even more compelling. An agency with 20 client sites needs to monitor uptime, SSL, DNS, and domain expiry for every single one. Doing that across separate tools means hundreds of individual configurations. A unified platform lets you manage all sites from one account with consistent alert policies, centralized reporting, and a single monthly invoice.

For a comparison of how this approach stacks up against using individual tools, see our individual tools comparison. For a broader look at the monitoring tool landscape, read website monitoring tools compared. You can also use our website downtime cost calculator to quantify the financial case for comprehensive monitoring.

References

[1] Gartner, "The Cost of Downtime," https://www.gartner.com/en/documents/3956877

[2] Google Search Central, "Avoid long redirect chains," https://developers.google.com/search/docs/crawling-indexing/301-redirects

[3] Sitemaps.org, "Sitemap file requirements," https://www.sitemaps.org/protocol.html

[4] Google Search Central, "Managing multi-regional and multilingual sites," https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites

[5] ITIC, "2024 Hourly Cost of Downtime Survey," https://itic-corp.com/itic-2024-hourly-cost-of-downtime-survey/