5xx server errors explained in plain English
Keeping a busy site available is hard work. When something goes wrong on the server you’ll often see a 5xx status code. This guide explains what those codes mean, why they happen, how they differ from client-side issues, and what to try before you call your developer. It finishes with quick, practical steps for .NET and Umbraco sites and how Growcreate can help if the problem keeps coming back.
What 5xx errors are
A 5xx status code tells you the server failed to complete a valid request. It’s not a browser or user problem – it’s a server-side issue. The HTTP standard classifies responses by their first digit: 2xx success, 3xx redirection, 4xx client error and 5xx server error. In short, 5xx means the server could not fulfil the request even though the request itself was fine. (Source: RFC 9110)
How 5xx differs from 4xx
- 4xx codes usually mean something about the request needs to change – for example the URL doesn’t exist (404) or you’re not authorised (401). The fix is often on the client side or in site configuration.
- 5xx codes mean the request was acceptable but the server could not respond correctly. The fix is on the hosting stack, application or its dependencies. (Source: RFC 9110)
Glossary of common 5xx codes
| Code | Name | What it means | Typical causes | What to try |
|---|---|---|---|---|
| 500 | Internal Server Error | Generic server failure when no more specific code fits. | Unhandled exceptions, misconfiguration, memory or permission issues. | Refresh. If it persists, contact the site owner. Admins should check server and app logs for the failing request. (Source: MDN) |
| 501 | Not Implemented | The server doesn’t support the request method or needed feature. | Unsupported HTTP method or extension. | End users can’t fix this. Server owners must add or enable support. (Source: MDN) |
| 502 | Bad Gateway | A gateway or proxy got an invalid response from the upstream server. | Reverse proxy or CDN to origin issues, TLS/certificate mismatch, upstream crash. | Try again. If persistent, check origin health, SSL mode and timeouts. (Source: MDN) |
| 503 | Service Unavailable | The server is temporarily overloaded or down for maintenance. Should include a Retry-After time. | Planned maintenance, traffic spike, exhausted resources. | Wait, then retry. Site owners should return 503 with a clear message and Retry-After. (Source: MDN, MDN Retry-After) |
| 504 | Gateway Timeout | A gateway or proxy didn’t get a timely response from upstream. | Slow origin, long-running queries, mismatched timeouts. | Retry. Admins should align proxy and origin timeouts and optimise slow operations. (Source: MDN) |
Why these codes matter for SEO and revenue
Google treats persistent 5xx errors as server problems. Crawlers will slow down and, if errors continue, affected URLs can eventually drop from the index. That means fewer pages being discovered while the site is unstable, plus lost organic traffic if problems persist. (Source: Google Search Central)
For visitors, 5xx errors block core tasks like checkout or downloads. Even a brief outage during a campaign hurts conversion. A clear status page, friendly error copy and fast incident response reduce the impact. For ongoing issues, the real win is fixing root causes so they don’t recur.
Quick checks before you call your developer
If you see a 5xx message as a visitor:
- Refresh the page or try again in a few minutes.
- Check if the whole site is down or only one page.
- If you’re behind a VPN or corporate proxy, try your mobile network.
- If the problem persists, contact the site owner with the time, URL and steps you took.
If you manage the site but don’t want to get deep into code:
- Look at your hosting or CDN status page to rule out a platform incident.
- If there’s a planned maintenance window, wait for the all clear.
- If it’s a shopfront or campaign page, pause paid traffic until stability returns.
- Log a ticket to your support partner with examples and timestamps so they can correlate logs.
Common causes of 500 errors on .NET and Umbraco
500 is a catch‑all, so the fix comes from what your logs show. Typical causes include:
- Unhandled exceptions raised by application code or dependencies.
- Invalid configuration files, missing environment variables or connection strings.
- Permissions on content or config files, especially after a deployment.
- App startup failures that surface as IIS 500.x variants, for example 500.30 when an ASP.NET Core app fails to start. These happen before Umbraco can boot, so you need server logs rather than CMS logs. (Source: Microsoft Learn – IIS/ASP.NET Core troubleshooting, Umbraco docs – 500s and startup issues, Umbraco 500.30 discussion)
A practical .NET checklist that doesn’t require deep engineering
- Confirm it’s not maintenance: if you planned downtime, ensure the site serves a friendly 503 page with a Retry-After header so browsers and crawlers know when to try again. (Source: MDN Retry-After)
- Note exact details: URL, time, and what you were doing. Your support team will pair these with server logs.
- Check your hosting control panel or cloud dashboard for red or failing checks.
- If you run on Windows/IIS, your support team may enable detailed errors or Failed Request Tracing to capture the failing request without reproducing it live. This is a standard, safe diagnostic step. (Source: Microsoft Learn – Failed Request Tracing)
- For Umbraco sites, errors in templates or controllers can produce 500s. Your developer can configure proper error pages in Umbraco and the web server so visitors don’t see raw errors. (Source: Umbraco custom error pages)
Troubleshooting 502 and 504 through proxies, CDNs and load balancers
Modern sites usually sit behind a reverse proxy, CDN or load balancer. That extra hop is often where 502 and 504 originate.
- Cloudflare 502/504: usually an origin issue. Identify whether the error comes from Cloudflare or your origin, then check origin health, DNS and TLS mode. Cloudflare outlines the steps and what to send their support if needed. (Source: Cloudflare 502/504)
- Azure Application Gateway: 502 often points to failing health probes, SSL name mismatches or backend timeouts. 504s occur when the gateway waits longer than the configured timeout. Align backend timeouts with your application server and ensure probes reach a healthy endpoint. (Source: Azure response codes, Azure 502 troubleshooting)
- AWS Application Load Balancer: 502 and 504 counters in metrics indicate connection resets or idle timeouts between the ALB and targets. Check security groups, target health and idle timeout settings. (Source: AWS ALB troubleshooting)
Business value: by treating the proxy and origin as one chain, you isolate issues faster and cut incident time.
Do these simple things to reduce repeat incidents
- Use health checks properly: expose a lightweight health endpoint for your app and let your load balancer remove unhealthy instances automatically. This keeps traffic away from failing nodes. (Source: .NET health checks overview)
- Set sensible timeouts end‑to‑end: make sure CDN, gateway and app timeouts line up so long‑running work doesn’t produce 504s.
- Add friendly maintenance pages: when you need downtime, return 503 with Retry‑After and helpful copy. This preserves user trust and reduces crawler pressure. (Source: MDN Retry-After)
- Monitor and alert: basic uptime monitoring plus application logs and error rates will catch problems before they become visible to customers.
Practical steps for teams running .NET and Umbraco
Use this lightweight routine when a 5xx appears:
Triage fast
- Confirm scope: one page, one section or whole site.
- Capture: URL, timestamp, user action, and any request ID shown on your error page.
- Pause paid traffic if conversion journeys are affected.
Stabilise
- If load is the issue, return a 503 with clear copy and a Retry‑After header while you scale up or fix the hotspot. (Source: MDN Retry-After)
- If an upstream is failing, switch to a cached or fallback variant where possible at the CDN.
Diagnose
- Review last deployment and config changes first.
- On IIS, enable Failed Request Tracing for the affected URL pattern to get a precise trace without guessing. (Source: Microsoft Learn – Failed Request Tracing)
- In Umbraco, check umbracoTraceLogs for exceptions in templates or controllers and ensure your server is configured to serve a static 500 page if the app fails before the pipeline starts. (Source: Umbraco troubleshooting, Umbraco custom error pages)
Prevent recurrence
- Add or tune health checks so unhealthy instances stop taking traffic, and align timeouts across CDN, gateway and app. (Source: .NET health checks, Azure response codes)
- Add clear error pages with request IDs, then keep a short playbook so on‑call teams always know the next action.
How Growcreate helps
If your site is critical and built on .NET, Umbraco or Azure, our team keeps it stable and fast with:
- Fast incident response with SLA targets so issues are triaged and resolved quickly.
- Root‑cause analysis and fixes, not just restarts.
- Proactive monitoring, alerting and health checks tailored to your stack.
- Security hardening and GDPR‑aligned operations for peace of mind.
- Clear incident reports and simple communication.
- Predictable support options – ad‑hoc credits or a monthly retainer.
- Integration with your existing CI/CD and observability tools.
- UK‑based support during business hours with out‑of‑hours cover.
- A track record across regulated sectors with case studies to match.
Explore related Growcreate services and guides
- 24/7 support for .NET, Umbraco and Azure with SLA response and monitoring: 24/7 support
- Dedicated Umbraco support with defined response and resolution times: 24/7 Umbraco support
- Enterprise hosting for Umbraco on Azure and Umbraco Cloud with SLAs: Umbraco hosting
- Modernise older platforms to improve stability and performance: Platform modernisation
- Thinking about roadmap and support lifecycles: UK Umbraco delivery guide 2026 and Umbraco end‑of‑life guide
When to call us
- 5xx errors are frequent or tied to peak periods
- Outages follow deployments or content releases
- You rely on a load balancer or CDN and see 502/504 under load
- You need SLAs, monitoring and clear ownership across vendors
If that sounds familiar, we’re ready to help.
If you’re seeing persistent 5xx errors or need dependable support for your .NET systems, speak to our team. We’ll stabilise the platform, find the root cause and keep you moving.
FAQs
It’s a general server failure. On .NET it’s commonly an unhandled exception, a misconfigured web.config or appsettings.json, a missing secret or a dependency (database, API) that failed during the request. Check server logs, then redeploy a fix or roll back the last change. If the app won’t boot at all, the web server may show IIS 500.x such as 500.30. (Source: Microsoft Learn – IIS/ASP.NET Core troubleshooting)
5xx means the server could not complete a valid request. 4xx means the request needs to change. That’s defined in the HTTP specification. (Source: RFC 9110)
Yes. Google slows crawling when it sees 5xx and, if they persist, can eventually drop affected URLs from the index. Even short outages harm campaigns and checkout flows, so plan maintenance carefully and respond quickly to incidents. (Source: Google Search Central)
Check if the error comes from the edge or your origin. Verify origin health checks, SSL mode and certificates, then align timeouts. Cloud providers document specific 502/504 causes and fixes. (Source: Cloudflare 502/504, Azure 502/504, AWS ALB troubleshooting)
