This guide explains what happens during a DDoS (Distributed Denial of Service) attack on your site and how EDGE automatically mitigates these attacks.

EDGE provides automatic DDoS protection that detects and mitigates DDoS attacks. This guide explains what happens during an attack and what actions you may need to take.

What is a DDoS Attack?

DDoS Attack Definition

  • Distributed Attack: Attack from multiple sources
  • Overwhelming Traffic: Overwhelming amount of traffic
  • Service Disruption: Attempts to disrupt service
  • Automated Mitigation: EDGE automatically mitigates attacks

Attack Types

Pressidium EDGE provides multi-layer DDoS protection across network and application layers. It helps mitigate large-scale floods, bot floods, scans, and application-layer attacks before they reach your origin.

During a DDoS attack, EDGE filters and blocks malicious traffic at the edge before it reaches your origin infrastructure. Legitimate traffic continues to be routed through the edge network where possible.

  • Volume-based attacks: Large traffic floods that try to overwhelm your site or origin infrastructure. EDGE helps absorb and filter this traffic at the edge before it reaches your server.
  • Protocol attacks: Attacks that abuse network or transport-layer behavior to exhaust connection capacity or infrastructure resources. EDGE helps mitigate these attacks before they impact your origin.
  • Application-layer attacks: HTTP/HTTPS attacks that target WordPress pages, login endpoints, XML-RPC, APIs, or other application routes. EDGE uses edge-level filtering, bot protection, and WordPress-aware security rules to block malicious requests.
  • Bot floods, scans, and automated abuse: Automated traffic from bots, scrapers, vulnerability scanners, or brute-force tools. EDGE helps identify and block abusive traffic patterns before they reach WordPress.

What Happens During an Attack

Automatic Detection

EDGE monitors incoming traffic at the edge and automatically evaluates requests before they reach your origin infrastructure. When traffic shows signs of abuse, such as unusual volume, repeated automated requests, suspicious access patterns, or known attack behavior, EDGE can apply mitigation at the edge.

  • Attack detection: EDGE identifies suspicious traffic patterns and malicious requests before they reach your WordPress origin.
  • Traffic analysis: EDGE evaluates request behavior, traffic volume, source patterns, and request targets to help distinguish abusive traffic from normal visitor activity.
  • Pattern recognition: EDGE uses edge-level filtering, bot protection, and WordPress-aware security rules to detect common attack behavior against WordPress sites.
  • Mitigation timing: Detection and mitigation are automatic. Exact timing can vary depending on the attack type, traffic pattern, and origin conditions.

Automatic Mitigation

EDGE automatically applies edge-level mitigation for malicious traffic, bot activity, and attack patterns. In many cases, no manual action is required from the site owner.

  • Mitigation activation: EDGE applies mitigation at the edge when traffic matches abusive patterns, known attack behavior, or WordPress-specific security rules.
  • Traffic filtering: EDGE filters incoming requests before they reach your origin. This helps reduce unwanted traffic, bot activity, scans, and attack requests.
  • Attack blocking: Malicious requests can be blocked at the edge, so they do not consume origin resources or reach WordPress.
  • Legitimate traffic: EDGE is designed to keep valid visitor traffic flowing while filtering abusive traffic where possible. During large or complex attacks, some users may still experience slower responses or temporary access issues.

Service Continuity

EDGE improves resilience during attacks by absorbing and filtering traffic before it reaches your origin. However, origin availability still depends on the health of the origin infrastructure.

  • Service availability: EDGE helps keep your site reachable by filtering abusive traffic at the edge and reducing the amount of unwanted traffic sent to your origin.
  • Performance impact: During large or complex attacks, some visitors may experience slower responses, temporary access challenges, or intermittent errors, especially if the origin is already under heavy load.
  • Legitimate user access: EDGE is designed to allow valid visitor traffic while blocking abusive requests where possible. If legitimate users report access issues, review recent security events and contact Support with the affected IP address, timestamp, and request details.
  • Service restoration: After the attack traffic subsides or mitigation stabilizes, normal traffic flow should return. Continue monitoring traffic, cache behavior, and origin health to confirm that the site is responding normally.

Attack Notifications

EDGE may surface attack-related activity through security events, traffic analytics, dashboard indicators, or support communication, depending on the type and severity of the event.

Do not rely on notifications alone during a suspected DDoS attack. If your site appears slow, unavailable, or under abnormal traffic pressure, check the dashboard and contact Support if the issue affects legitimate users or origin stability.

What you may see

Depending on the event and available data, you may see:

  • Security events: Blocked requests, suspicious traffic, or firewall-related activity.
  • Traffic changes: Sudden increases in requests, bandwidth, or unusual traffic patterns.
  • Origin impact: Slower response times, intermittent errors, or increased origin load.
  • Support updates: For significant incidents, Support may provide guidance or request additional details.

Notification methods

Notification methods can vary by account, configuration, and incident severity. Check the Pressidium Dashboard first for available traffic and security information.

Do not mention SMS alerts unless your account or product plan explicitly supports them.

What You Need to Do

In most cases, EDGE handles DDoS mitigation automatically at the edge. Your main role is to monitor the site, check whether legitimate users are affected, and contact Support if the attack causes visible service impact.

During an Attack

Typically no manual action is required:

  • EDGE automatically filters and blocks abusive traffic at the edge.
  • Malicious requests are reduced before they reach your origin.
  • Valid visitor traffic should continue where possible.
  • Some visitors may still experience slower responses or temporary errors during large or complex attacks.

Recommended actions:

  • Monitor traffic activity: Review Traffic Analytics for request spikes, unusual bandwidth changes, or repeated traffic to specific paths.
  • Review security activity: Check Security Events Analytics for blocked requests, firewall activity, or suspicious request patterns.
  • Check site availability: Test important pages from a normal browser session and confirm whether the issue affects all visitors or only specific regions, IPs, or paths.
  • Check origin health: If the site remains slow or unavailable, review origin response behavior, server load, and error logs where available.
  • Avoid unnecessary changes: Do not change DNS, disable protection, or remove security rules during an active attack unless Support instructs you to do so.

After an Attack

After traffic returns to normal, review what happened and confirm that the site is stable.

  1. Review traffic activity: Check when abnormal traffic started, when it peaked, and when it returned to normal.
  2. Review security activity: Look for blocked requests, repeated attack patterns, affected paths, or suspicious source patterns.
  3. Check service impact: Confirm whether visitors experienced slow loading, errors, blocked access, or checkout/login issues.
  4. Check origin recovery: Confirm that origin response times, error logs, and server load have returned to normal.
  5. Document the event: Record the affected domain, approximate timeline, visible impact, dashboard findings, and any actions taken.

Attack Information

During or after a suspected DDoS attack, use the available dashboard data to review traffic and security activity. The information available may vary depending on the event, the site configuration, and the data shown in your account.

To review activity during a suspected attack:

  1. Open the Pressidium Dashboard.
  2. Select the affected site.
  3. Review Traffic Analytics for unusual request volume, bandwidth changes, or traffic spikes.
  4. Review Security Events Analytics for blocked requests, firewall activity, or suspicious request patterns.
  5. Check origin health and response behavior if visitors are still seeing errors or slow responses.

Use this information to understand whether the issue appears to be traffic-related, security-related, origin-related, or a combination of these.

Information you may be able to review

Depending on the event and available dashboard data, you may be able to review:

  • Traffic patterns: Sudden increases in requests, bandwidth, or repeated requests to specific paths.
  • Blocked requests: Firewall or security events that show abusive or suspicious traffic being blocked.
  • Affected paths: URLs, endpoints, or WordPress routes receiving unusual traffic.
  • Source patterns: Repeated traffic from specific IP addresses, regions, user agents, or automated clients, where available.
  • Origin impact: Slow responses, elevated errors, or increased origin load during the event.
  • Timeline: Approximate time periods when abnormal traffic or blocked activity was visible.

What to record for Support

If you contact Support, include:

  • The affected domain and site.
  • The approximate start time and duration of the issue.
  • Screenshots or exports from Traffic Analytics and Security Events Analytics, if available.
  • Example affected URLs.
  • Any affected visitor IP addresses, regions, or user agents, if known.
  • The visible impact, such as slow loading, intermittent errors, blocked legitimate users, or origin overload.

DDoS Protection Settings

DDoS protection in EDGE is managed at the edge by Pressidium. In most cases, you do not need to configure DDoS mitigation manually or choose a protection level.

Instead, use the available traffic, security, and firewall controls to review activity and adjust how your site handles specific request patterns.

What you can review or adjust

Depending on your site configuration and account permissions, you may be able to:

  • Review traffic activity: Use Traffic Analytics to check request volume, bandwidth changes, traffic spikes, and affected paths.
  • Review security activity: Use Security Events Analytics to inspect blocked requests, suspicious activity, and firewall-related events.
  • Review firewall rules: Check whether custom firewall rules are blocking or allowing specific traffic.
  • Create targeted rules: Use firewall or traffic rules to block specific IP addresses, countries, user agents, paths, or request patterns when appropriate.
  • Allow legitimate traffic: Adjust rules carefully if valid users are being blocked.

What not to change during an active attack

During an active attack, avoid making broad changes that could affect all traffic unless Support instructs you to do so.

Avoid:

  • Disabling security protections.
  • Removing firewall rules without reviewing their impact.
  • Changing DNS records while traffic is unstable.
  • Creating broad allow rules that could let abusive traffic reach your origin.
  • Blocking large regions without confirming where legitimate users are located.

Best Practices

DDoS preparedness

  • Know your normal traffic patterns: Review traffic analytics regularly so unusual request spikes are easier to identify.
  • Keep important URLs easy to test: Know which pages matter most, such as the homepage, login page, checkout, product pages, or key landing pages.
  • Review custom rules carefully: Make sure firewall or traffic rules do not accidentally block legitimate users.
  • Keep access to Support ready: Know who on your team can contact Support during a security or availability issue.
  • Document major events: Record timelines, affected domains, visible impact, and dashboard findings for future review.

Response planning

  • Understand what EDGE handles automatically: EDGE mitigates abusive traffic at the edge, but origin health still matters.
  • Know what to monitor: Check traffic analytics, security events, affected URLs, origin response behavior, and user reports.
  • Avoid broad emergency changes: Do not change DNS, disable protection, or create broad allow rules during an attack unless Support instructs you to do so.
  • Review the event afterward: After traffic stabilizes, review what happened and decide whether any firewall or traffic rules need adjustment.

Common issues and solutions

Issue: The site is still slow or unavailable during an attack

Symptoms: Visitors report slow loading, intermittent errors, timeouts, or unavailable pages during suspected attack traffic.

Likely causes:

  • The attack is large, complex, or changing quickly.
  • The origin is already under heavy load.
  • Some requests are bypassing cache and reaching WordPress.
  • A specific endpoint, such as login, checkout, search, XML-RPC, or an API route, is being targeted.
  • A custom rule is not strict enough for the current traffic pattern.

Resolution steps:

  1. Review Traffic Analytics for request spikes, affected paths, bandwidth changes, or unusual regions.
  2. Review Security Events Analytics for blocked requests and suspicious request patterns.
  3. Check whether the affected pages are cacheable or whether requests are reaching the origin.
  4. Check origin health, server load, and error logs where available.

Issue: Legitimate users are blocked or challenged

Symptoms: Real visitors report blocked requests, failed access, or unexpected security responses.

Likely causes:

  • A custom firewall rule is too broad.
  • A country, IP range, user agent, or path-based rule is affecting valid traffic.
  • Attack traffic resembles legitimate visitor behavior.
  • A user is accessing the site from a shared network, VPN, proxy, or region affected by stricter filtering.

Resolution steps:

  1. Ask the affected user for their IP address, approximate timestamp, URL, and screenshot of the error.
  2. Review Security Events Analytics for matching blocked requests.
  3. Check any custom firewall, country, IP, user agent, or path-based rules.
  4. Adjust only the specific rule causing the issue.

Issue: Attack traffic appears to continue after mitigation

Symptoms: Traffic analytics still shows high request volume after mitigation is active.

Likely causes:

  • EDGE is still receiving and filtering attack traffic at the edge.
  • The attack is ongoing but being partially or fully blocked before reaching the origin.
  • Some requests are legitimate traffic from a campaign, crawler, integration, or monitoring system.
  • The origin is still recovering from earlier load.

Resolution steps:

  1. Compare total request volume with origin errors and response times.
  2. Review blocked security events to confirm whether abusive traffic is being filtered.
  3. Check whether important pages are loading for normal visitors.
  4. Continue monitoring until request volume and origin behavior stabilize.

Need help?

Contact Support if:

  • The site remains slow, unavailable, or unstable during suspected attack traffic.
  • Legitimate users are blocked or challenged.
  • Your origin remains under heavy load after mitigation.
  • You see repeated attacks against login, checkout, XML-RPC, API, or other sensitive paths.
  • You are unsure whether a traffic spike is legitimate or abusive.
  • You need help reviewing security events, traffic analytics, or custom rules.

Include the following information:

  • Affected domain and site.
  • Approximate start time and duration.
  • Example affected URLs.
  • Screenshots or exports from Traffic Analytics and Security Events Analytics, if available.
  • Affected visitor IP addresses, regions, or user agents, if known.
  • Error messages, screenshots, or status codes users are seeing.
  • Any recent DNS, firewall, cache, plugin, theme, or origin infrastructure changes.

See: Open a Support Request

Where to go next