Type: Troubleshooting
Category: Umbraco Cloud > Downtime
Tags: downtime, DoS, DDoS, denial of service, bot attack, bot traffic, traffic surge, site down, WAF, web application firewall, Cloudflare, rate limiting, block IP, managed challenge, traffic spike
Product: Umbraco Cloud, Umbraco CMS
Version: All versions
Summary
If your site went down under a sudden surge of traffic, the cause may be a Denial-of-Service (DoS), Distributed Denial-of-Service (DDoS), or bot attack. This article covers how to confirm that, what to do while an attack is active, and how to reduce the risk of it happening again.
Symptoms
The site becomes slow or unavailable with no deployment, code change, or upgrade to explain it.
Traffic volume spikes far above normal, often from a narrow set of IP addresses or regions.
Error rates and resource usage rise together, and recover when traffic drops.
Not every traffic-driven outage is an attack. If there was no unusual traffic volume, see What are the common causes of site downtime and how can they be resolved? instead.
Understanding the cause
DoS and bot-driven attacks work by flooding a site with enough requests to exhaust its resources. The difficulty is that bot traffic often mimics legitimate visitors, so volume alone does not tell you what you are looking at.
To confirm it, you need traffic characterization for the period of the outage: request volume over time, source IPs and regions, user agents, and which paths were hit. A traffic characterization report is usually what establishes that a bot surge, rather than genuine demand or an internal fault, caused the downtime.
Investigating
On Umbraco Cloud
Open a support ticket and ask for a downtime investigation covering the affected period. Include the date, time, and time zone of the outage, the hostname affected, and anything you have already observed. See Downtime investigation for what to include.
Umbraco Cloud sits behind Cloudflare, so the traffic data needed to characterize an attack is on our side. You cannot pull it from the Cloud Portal yourself.
If you host Umbraco yourself
Pull the request logs and CDN or WAF analytics for the outage window yourself, and look for a narrow set of source IPs, unusual user agents, or a single path taking a disproportionate share of requests.
Mitigating an active attack
On Umbraco Cloud
Check that WAF is enabled on the affected hostname. In the Cloud Portal, go to Security → Transport Security. WAF is enabled by default on custom hostnames, but confirm it for the hostname under attack. Note that WAF is not available on internal Cloud hostnames, and it cannot be enabled if your project sits behind a proxy server.
Contact support for targeted rules. Blocking specific IP addresses or regions, and applying bot management rules, is handled by our support team rather than from the portal. Open a ticket describing the traffic pattern you are seeing (if you're already talking to Umboto, just type "talk to human").
Validate that the mitigation worked. Keep watching traffic volume and error rates after rules are applied, to confirm the attack traffic is actually being filtered rather than shifting to another path or source.
If you host Umbraco yourself
Block the offending sources at your WAF or CDN, applying the rules at the hostname level so the traffic is filtered before it reaches your site.
Validate the same way: watch traffic volume and error rates until they return to normal.
Reducing the risk of future attacks
Keep WAF enabled on all custom hostnames. On Umbraco Cloud it applies Cloudflare's managed rulesets against common attack techniques such as cross-site scripting, SQL injection, and file inclusion. See How to configure and manage Web Application Firewall (WAF) on Umbraco Cloud? for the sensitivity settings and what each one does.
Use bot management to challenge or throttle abusive automated traffic, rather than blocking outright where you risk catching real visitors. Which bot controls are available to you depends on your setup, so ask support what applies to your project.
Consider rate limiting on endpoints that attract abuse, such as search, login, and form submissions.
Be careful with region blocking. It can help if your audience is geographically bounded, but check your actual visitor data first. Blocking a region that contains legitimate users is an outage you caused yourself.
Review traffic analytics regularly so you notice an emerging pattern before it takes the site down, and refine your rules as attack patterns change.
Still having issues?
If you are chatting with Umboto right now, type "talk to human" and we will connect you with someone who can help.
If you are reading this article in the Help Center, contact us by clicking at the messenger icon at the bottom right.
Related articles
Recommended documentation
Last updated on August 26, 2026