Introduction

A maintenance site is useful during a migration, but it becomes a problem when production traffic still reaches it after the cutover is supposed to be complete. The live application may already be healthy, the new environment may already be serving normally, and yet some users still land on a temporary maintenance page because one routing layer still treats the maintenance destination as active. This creates a confusing situation where monitoring shows the site is healthy but users report seeing maintenance pages.

Treat this as a routing and failover problem instead of assuming the site itself is still down. Start by identifying which layer is actually sending users to the maintenance site, because the main production route can be correct while a fallback rule, backend, or health trigger keeps reviving the temporary page. This issue is particularly common in migrations that use multiple routing layers like load balancers, CDNs, and traffic managers.

The problem frequently appears after migrations where maintenance mode was enabled at multiple layers (load balancer rules, CDN configuration, application-level maintenance pages), DNS-based failover migrations, or blue-green deployments where the maintenance environment remains configured but should have been disabled. Organizations often enable maintenance routing at several points for safety but forget to clean up all layers after the migration completes.

Symptoms

  • Some users still see a maintenance page after the new site is back online
  • The problem affects only certain paths, regions, or repeated requests
  • Monitoring says the live service is healthy, but users still report downtime or maintenance banners
  • Direct checks to the application work while normal public traffic still lands on the maintenance site
  • The issue started right after a migration, recovery event, or production cutover
  • Refreshing or testing from another network produces different results
  • Load balancer or CDN shows the maintenance backend still receiving traffic
  • Specific URLs or paths show maintenance while others work correctly
  • Regional users are affected while others access the live site normally
  • Health check endpoints work but user-facing pages show maintenance

Common Causes

  • A fallback route or listener rule still points to the maintenance site in load balancer configuration
  • Health-based failover still considers the live backend unhealthy and keeps switching traffic away
  • The maintenance backend remains in a target group, pool, or reverse-proxy config as an active member
  • Hostname or path-based routing still matches a temporary maintenance rule created during cutover
  • Only the main production path was restored while error, fallback, or standby routes were left unchanged
  • Teams fixed the application but did not fully remove the maintenance routing layer afterward
  • CDN edge locations cached the maintenance page and haven't purged
  • DNS failover still routes to the maintenance IP for some users
  • Default virtual host serves maintenance page when expected host header is missing

Step-by-Step Fix

  1. 1.Capture the exact hostname, path, and request pattern that still reaches the maintenance site using curl or browser developer tools, because you need the real matching route before changing any production rule.
  2. 2.Compare a request that reaches the live site with one that reaches the maintenance site by examining headers, IPs, and routing paths, because the difference often reveals whether the bad path is tied to a specific listener, region, host rule, or failover condition.
  3. 3.Review load balancer rules, reverse-proxy config (Nginx, Apache, HAProxy), CDN routing (Cloudflare, CloudFront), and traffic-manager logic for references to the maintenance destination, because the temporary page usually survives in one secondary routing layer after cutover.
  4. 4.Check health checks and failover triggers for the live backend in the load balancer or traffic manager console, because a healthy main route does not matter if the system still believes the production target should fail over to maintenance.
  5. 5.Inspect target groups, backend pools, and standby destinations for leftover maintenance members that are still active, because a stale backend can keep serving traffic even after the visible primary route looks correct.
  6. 6.Remove or disable the maintenance route only after confirming the live application is stable enough to serve production traffic continuously, because cutting away the safety path too early can create a harder outage.
  7. 7.Retest from fresh sessions and more than one network after the change, because caches, sticky routing, or regional propagation can make the maintenance path appear fixed in one place and still active in another.
  8. 8.Confirm in backend logs and analytics that the maintenance site stops receiving real production requests, because the routing layer is not fully corrected until that temporary destination goes quiet.
  9. 9.Restrict, retire, or document the maintenance path once recovery is complete, because temporary cutover routes often cause repeat incidents when they remain available but forgotten.

Verification

Confirm the fix is complete:

  1. 1.Test the affected URLs from multiple networks and browsers to verify consistent access to the live site
  2. 2.Check load balancer metrics to confirm the maintenance backend receives no traffic
  3. 3.Verify health checks show the live backend as healthy across all regions
  4. 4.Monitor user reports to confirm no more maintenance page complaints
  5. 5.Test failover scenarios to ensure the system fails over correctly, not to the maintenance page

Prevention

To avoid this issue in future migrations:

  • Create a cleanup checklist for all maintenance routing layers before ending the migration
  • Use distinct naming conventions for maintenance backends to make them easy to identify
  • Remove maintenance routes immediately after cutover, not as a later cleanup task
  • Test from external networks after migration to verify maintenance pages are not served
  • Document all places where maintenance mode was enabled for systematic cleanup
  • Consider automated checks that verify no maintenance routes are active in production
  • Set alerts for traffic to maintenance backends after the cutover window
  • [Fix Fix 413 Request Entity Too Large Issue in Downtime](fix-413-request-entity-too-large)
  • [Fix Fix 499 Client Closed Request In Nginx Issue in Downtime](fix-499-client-closed-request-in-nginx)
  • [Fix Fix 500 Internal Server Error in Downtime](fix-500-internal-server-error)
  • [Fix Fix 502 Bad Gateway Issue in Downtime](fix-502-bad-gateway)
  • [Fix Fix 503 Service Unavailable Issue in Downtime](fix-503-service-unavailable)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "How to Fix Traffic Still Routing to a Maintenance Site After Cutover", "description": "Resolve traffic still routing to a maintenance site after cutover by checking fallback routes, listener rules, failover triggers, and stale maintenance backends.", "url": "https://www.fixwikihub.com/fix-traffic-still-routing-to-maintenance-site-after-cutover", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2025-10-31T05:29:46.933Z", "dateModified": "2025-10-31T05:29:46.933Z" } </script>