Monitoring Subdomains: Ensure All Parts of Your Website Stay Up

Most businesses treat their website as a single entity. They set up monitoring on www.example.com, see a green checkmark, and assume everything is fine. But modern web applications are built on a network of subdomains -- shop.example.com handles e-commerce, api.example.com serves the mobile app, blog.example.com drives organic traffic, and portal.example.com handles customer logins. Each of these subdomains can fail independently while the main site keeps humming along. Without dedicated subdomain monitoring, you are flying blind over some of the most critical parts of your infrastructure.

Why Subdomains Fail Independently

Subdomains often run on different servers, containers, or even different hosting providers. A typical setup might look like this:

• www.example.com -- hosted on a CDN like Cloudflare or AWS CloudFront
• shop.example.com -- running on a Shopify integration or a separate e-commerce server
• api.example.com -- deployed on Kubernetes or a dedicated API gateway
• blog.example.com -- powered by WordPress on its own VPS
• mail.example.com -- managed by an external email service
• cdn.example.com -- pointing to a storage bucket or media server

Because these services run on separate infrastructure, a failure in one does not necessarily affect the others. Your main website could show perfect uptime while your API subdomain has been returning 502 errors for the past two hours -- and your mobile app users are the only ones who notice.

The Real-World Cost of Unmonitored Subdomains

Consider these scenarios that happen more often than most teams realize:

Scenario 1: The Silent E-Commerce Outage

An online retailer runs their storefront on shop.example.com. During a holiday sale, the shop subdomain runs out of memory due to traffic spikes. The main marketing site on www.example.com stays up, so the monitoring dashboard shows green. Meanwhile, customers clicking "Buy Now" get error pages. The team only discovers the problem 45 minutes later when a customer tweets about it. At $12,000 per hour in revenue, that 45-minute delay cost them $9,000 in lost sales -- plus the unquantifiable damage of frustrated shoppers who will not come back.

Scenario 2: The Expired SSL on the API Subdomain

A SaaS company has an SSL certificate for their main domain that auto-renews perfectly. But their API subdomain uses a separate certificate managed by a different team member. When that certificate expires, every mobile app and third-party integration that relies on api.example.com starts failing with SSL errors. The main website looks fine. The API subdomain has been broken for six hours before the on-call engineer gets paged by a partner company complaining about integration failures.

Scenario 3: The Blog DNS Misconfiguration

After a DNS provider migration, a team updates all their records but forgets the CNAME for blog.example.com. The blog -- which generates 40% of organic search traffic -- starts returning NXDOMAIN errors. Google deindexes the blog pages within days. By the time someone notices, the company has lost weeks of SEO equity that will take months to recover.

What to Monitor on Each Subdomain

Effective subdomain monitoring goes beyond a simple ping. Each subdomain needs a tailored set of checks based on what it does:

Step-by-Step: Setting Up Subdomain Monitoring with UptyBots

Here is a practical walkthrough for setting up comprehensive subdomain monitoring:

Step 1: Inventory All Your Subdomains

Before you can monitor subdomains, you need to know what you have. Many organizations discover forgotten subdomains during this exercise. Check your DNS provider for a full list of records, and look for:

• A records and CNAME records pointing to active services
• Subdomains created for one-time campaigns that are still live
• Development or staging subdomains exposed to the public internet
• Third-party service subdomains (help desk, knowledge base, status page)

Step 2: Create Individual Monitors for Each Subdomain

In UptyBots, add each subdomain as a separate target. This gives you independent alerting and uptime tracking per subdomain. Do not rely on a single monitor for your root domain -- that only tells you about one piece of the puzzle.

Step 3: Configure the Right Check Type for Each

Match your monitoring type to the subdomain's function:

• HTTP/HTTPS checks for web-facing subdomains -- verify status codes, response time, and optionally check for specific content on the page
• Port monitoring for services that do not serve web pages -- databases, mail servers, custom TCP services
• SSL monitoring for every subdomain using HTTPS -- catch expiring certificates before they break connections. Use our SSL Expiry Countdown tool to check current certificate status
• Synthetic monitoring for subdomains with login flows or multi-step interactions -- verify the entire user journey, not just the landing page
• Ping/ICMP for infrastructure subdomains where you need basic reachability data -- though be aware that some hosts block ping

Step 4: Set Up Alerts Per Subdomain

Configure separate alert policies for each subdomain based on its criticality:

• Revenue-critical subdomains (shop, checkout, API): alert immediately on first failure, notify via email and Telegram or webhook
• Important but not revenue-critical (blog, docs, status page): alert after 2-3 consecutive failures to reduce noise from brief blips
• Internal subdomains (staging, dev tools): alert via email only, with a longer threshold

Step 5: Review and Audit Regularly

Subdomain infrastructure changes over time. Set a quarterly reminder to:

1. Check your DNS for new subdomains that need monitoring
2. Remove monitors for decommissioned subdomains
3. Verify that SSL certificates across all subdomains have adequate remaining validity
4. Review alert history for patterns -- are certain subdomains consistently flaky?

Common Subdomain Monitoring Mistakes

Even teams that do monitor subdomains often fall into these traps:

Mistake 1: Only Monitoring the Root Domain

A green checkmark on example.com tells you nothing about api.example.com or shop.example.com. Each subdomain is a separate service that needs its own monitor.

Mistake 2: Ignoring SSL Per Subdomain

Wildcard certificates (*.example.com) simplify SSL management, but they are not universal. Many setups use separate certificates for specific subdomains. Even with wildcards, the certificate still expires -- and if your auto-renewal breaks, every subdomain goes down at once.

Mistake 3: Not Testing from Multiple Locations

A subdomain might resolve correctly in one region but fail in another due to DNS propagation issues or CDN misconfigurations. Multi-location monitoring catches these regional failures that single-location checks miss.

Mistake 4: Forgetting Temporary or Campaign Subdomains

Marketing teams spin up subdomains for campaigns (promo.example.com, launch.example.com). These often get forgotten but remain live. Unmonitored, they can develop security vulnerabilities or serve stale content that damages your brand.

Mistake 5: Using Only Ping Checks

Ping tells you a server is reachable at the network level. It says nothing about whether the web service on that server is actually functioning. An ICMP ping can succeed while the application is crashing on every request. Always combine ping with HTTP or API checks for meaningful coverage.

Subdomain Monitoring Checklist

Use this checklist when setting up subdomain monitoring for a new project or auditing an existing setup:

1. List all active subdomains from your DNS provider
2. Classify each subdomain by criticality (revenue, customer-facing, internal)
3. Create a separate monitor in UptyBots for each active subdomain
4. Add HTTP/HTTPS checks for all web-facing subdomains
5. Add SSL expiry monitoring for every subdomain using HTTPS
6. Add port checks for non-web services (mail, database, custom TCP)
7. Configure alert thresholds per subdomain based on criticality
8. Enable multi-location monitoring for subdomains served via CDN
9. Set up at least two notification channels (e.g., email + Telegram)
10. Schedule quarterly audits to catch new or decommissioned subdomains
11. Document your subdomain inventory and which team owns each one

How UptyBots Makes Subdomain Monitoring Simple

UptyBots is built for exactly this kind of multi-target monitoring. Here is what makes it practical for managing subdomains at scale:

• Multiple check types per target -- monitor HTTP, SSL, port, and ping for the same subdomain from a single dashboard
• Independent alerting -- each subdomain gets its own alert rules, so a blog blip does not wake up the on-call engineer at 3 AM
• Multi-location checks -- verify that subdomains are reachable from different geographic regions, not just your office
• SSL expiry tracking -- get alerted days or weeks before any subdomain certificate expires
• Flexible notifications -- route alerts to the right team via email, Telegram, or webhook integrations
• Historical uptime data -- track per-subdomain uptime over time to identify patterns and problematic services

Use our Downtime Cost Calculator to estimate how much unmonitored subdomain outages could be costing your business.

Frequently Asked Questions

How many subdomains should I monitor?

Monitor every subdomain that serves traffic to users, partners, or internal teams. If a subdomain is active in your DNS and serves any purpose, it should have at least a basic HTTP and SSL check.

Can I use a wildcard monitor instead of individual subdomain monitors?

No. Wildcard DNS records route traffic, but monitoring needs to target specific endpoints. Each subdomain may run different software, have different expected responses, and require different alert thresholds. Individual monitors give you the granularity you need.

What about subdomains on third-party services?

You should still monitor them. Even if Shopify or Zendesk hosts your subdomain, outages on their end affect your customers. External monitoring confirms that the third-party service is actually delivering your subdomain correctly.

How often should subdomain checks run?

For revenue-critical subdomains (shop, API, checkout), check every 1-5 minutes. For supporting subdomains (blog, docs), every 5-10 minutes is usually sufficient. SSL checks can run less frequently -- once or twice per day is enough to catch upcoming expirations.

See setup tutorials or get started with UptyBots monitoring today.