Skip to main content

Site downtime caused by DoS, DDoS, or bot attacks

How to confirm that a traffic surge caused your downtime, what to do while a DoS, DDoS, or bot attack is active on Umbraco Cloud or self-hosted, and how to reduce the risk of it recurring.

Written by Joana Knobbe

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, WAF sensitivity, Cloudflare, rate limiting, block IP, block referrer, block country, managed challenge, traffic spike, hotlinking, scraping, Unexpected end of Stream

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 true demand or an internal fault, caused the downtime.
​

Rule out the look-alikes first

Three things regularly look like an attack and are not. Checking these first saves you from applying rules that will not help.

  • Hotlinking. A single third-party site embedding one of your media files can generate enormous traffic from one referrer. If nearly all the requests hit one media path and come from one referring domain, this is hotlinking, not an attack, and the fix is different (see below).

  • Log noise without an outage. Automated traffic sending malformed POST requests can fill your error log while the site stays up. A common signature is System.IO.IOException: Unexpected end of Stream, the content may have already been read by another component. raised from ContentFinderByPageIdQuery.TryFindContent. This is background bot traffic, not a fault in your code. If CPU is healthy and real visitors are unaffected, it can safely be ignored.

  • A platform restart. An unexplained outage with no deployment and no traffic spike — often returning HTTP 500.30 — is more likely an infrastructure event than an attack. Traffic volume before the drop is what separates the two: an attack shows elevated requests and resource usage first, a restart does not.

Investigating

On Umbraco Cloud

​

You can check the edge traffic data yourself.

  • In the Cloud Portal, open the project's Traffic & Performance page and select at least one hostname to enable edge analytics.

  • Cloudflare edge analytics are now surfaced in the Portal at /project/<alias>/performance

    This gives you request counts, data transfer, and a breakdown by path and referrer. The edge numbers are estimates rather than exact counts, but they are usually enough to distinguish a surge from normal traffic and to see whether requests are concentrated on a single path.

Two things are not in the portal and are worth asking support for: a fuller Cloudflare traffic report for the affected window, and Cloudflare Bot Analytics, which scores how much of your traffic is automated. Ask for these if the portal data does not identify the source.

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

  1. 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. Transport Security has both Default Settings and Hostname Specific Settings, so check that the hostname under attack has not been left on different settings from the rest. Note that WAF is not available on internal Cloud hostnames, and it cannot be enabled if your project sits behind a proxy server.

  2. Turn on Managed Challenge, and raise WAF sensitivity. Both are self-service in the portal. Managed Challenge presents a lightweight JavaScript check that filters automated traffic while letting real visitors through with a cookie valid for 30 minutes. On sensitivity: the firewall works at any setting — the setting only changes how aggressively requests are blocked. Low blocks with high confidence and therefore blocks fewer requests; High blocks with medium confidence and filters more. While an attack is degrading the site, High is usually the right choice.

  3. If the traffic comes from one referrer or one country, you can block it yourself. Add a rewrite rule to your project's configuration file that matches on the referrer header and returns a 403 response. This is the right tool for hotlinking, where one identifiable site is pulling your content. Be aware that the referrer header can be spoofed and is often absent, so it will not stop a deliberate attacker. You can block by country the same way, matching on the Cloudflare country header with a two-letter country code.
    ​
    ​

    xml
    <rule name="Block referrer" stopProcessing="true">   <match url=".*" />   <conditions>     <add input="{HTTP_REFERER}" pattern="example\.com" ignoreCase="true" />   </conditions>   <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Access Denied" />   </rule>

    Country block:

    <rule name="Block country" stopProcessing="true">
      <match url=".*" />
      <conditions>
        <add input="{HTTP_CF_IPCOUNTRY}" pattern="^XX$" />
      </conditions>
      <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Access Denied" />
    </rule>

  4. Targeted rules. Blocking specific IP addresses or regions, and applying bot management rules: view documentation here.

  5. 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

  1. 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.

  2. 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 Managed Challenge to challenge or throttle abusive automated traffic, rather than blocking outright where you risk catching real visitors. It is available to you in the portal under Security → Transport Security, and you are free to adjust it yourself.

  • Add ReCaptcha to your Umbraco Forms if you have not already. Form endpoints are a common target, and WAF rules alone do not cover form abuse.

  • Consider rate limiting on endpoints that attract abuse, such as search, login, and form submissions.

  • Prefer an allowlist over a blocklist if your audience is geographically bounded. Blocking everything and then allowing the markets you actually serve is more durable than chasing individual sources. Check your real visitor data before you do it — blocking a region that contains legitimate users is an outage you caused yourself. Note also that Continent Managed Challenge will challenge services you may want, including Google's search indexing bot.

  • 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.

  • Open a support ticket (or type "human", if you're already talking to Umboto) 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.

Related articles

Recommended documentation

Last updated on August 26, 2026

Did this answer your question?