Discover the 76% : The API Traffic Your Security Tools Never See - Register Now !

Learning Center

Sudden Traffic Spike: Attack vs Marketing vs Crawler

8 min read April 17, 2026 Learning Center

It’s 11pm. Your monitoring fires. Traffic just spiked 400% and your site is crawling.

For the DevOps engineer managing infrastructure stability or the security engineer watching for active threats, this is the same moment with very different stakes. One of you is thinking about availability and whether to scale. The other is thinking about whether to block. Both of you need the same answer first, what is actually causing this spike.

Is this a DDoS? A campaign that finally landed? A crawler gone rogue? Three completely different situations. Three completely different responses. And you have minutes, not hours, to decide which one you are dealing with.

Block the wrong traffic and you have just killed conversions during your best moment. Miss a real attack and availability drops, and everyone will want to know why you didn’t catch it sooner.

This guide is built for that exact moment. It gives you a 60-second classification checklist to make an initial call fast, and a step-by-step confirmation workflow to know for certain what you are dealing with, so you act on the right information, not the wrong instinct.

60-Second Traffic Spike checklist

  • Endpoint concentration: Is one specific route, login, checkout, /api/*, being hammered disproportionately? That points to DDoS or an aggressive bot, not organic users.
  • Source diversity: Are sources scattered across normal ISPs and mobile networks? That is a marketing spike. Are they concentrated in data center ASNs or unusual geographies? Investigate further.
  • Conversion signals: Are signups, purchases, or real sessions rising? That is organic traffic. Zero conversions at high volume is a red flag for attack or bot.
  • What do the user agents look like? Real browsers in normal ratios point to organic users. Blank, identical, or spoofed headers point to a bot or attack.
  • Known trigger: Did a press mention, email campaign, or product launch go out in the last few hours? If yes, organic spike is the first assumption until the data says otherwise.

If two or more of these signals point in the same direction, you have enough to form a working hypothesis and act.

Fast classification table

Traffic Spike Signal DDoS Attack Marketing / Viral Crawler / Bot
Volume & speed Sudden surge, often 10–100x, in seconds to minutes Gradual ramp after a trigger (email, post, press), then fades Steady or pulsed, predictable cadence
Geographic spread Often narrow, one country, region, or ASN cluster Broad and diverse, matches known audience Single or few ASNs (AWS, GCP, Datacenters)
Source IPs / ASNs Unusual mix, spoofed, residential botnets, or concentrated datacenter ISPs, mobile networks, known organic sources Known crawler ASNs or IP ranges (Googlebot, Semrush, etc.)
Endpoints hit Concentrated on one route: login, checkout, /api/* Spread across landing page, product pages, referral flows Sitemap pages, /robots.txt, resource URLs
User-agent patterns Blank, spoofed, or unusual strings at unnatural volumes Real browsers, Chrome, Safari, Firefox in natural ratios Declared crawler UAs (Googlebot, AhrefsBot, etc.)
Conversion / engagement Zero or near-zero — no sessions, no purchases, no events Positive rising — signups, carts, real sessions Zero — no JS execution, no form fills
Cache behavior Hammers dynamic, uncacheable endpoints Benefits from cache — static pages see high hit ratios High hit ratio on cached pages, low origin impact
Server response CPU, DB, memory spike; 5xx errors climb fast Load increases but scales with autoscaling; few errors Origin load manageable unless volume is extreme
Time pattern Sustained, pulsed, or random bursts — no clear business trigger Traceable to a known event — launch, campaign, media Scheduled, crawl-paced, predictable timing

Confirmed it is an attack? Get immediate help now.

If your analysis points to a real attack and your site is slowing down or throwing errors, you don’t have to handle it alone.

Reach out via the Indusface Under Attack page and our security engineers join a live session immediately, validating the signal using real-time traffic analytics, identifying exactly what is being targeted (bandwidth, connections, or application endpoints), and applying managed mitigations until the incident is fully resolved

How to Read a Sudden Traffic Spike: Five Signals That Tell You What It Is

You have a sudden spike. Here is how to read it. Don’t start with the volume number. Volume tells you something is happening, it does not tell you what. Start with the shape, the source, and the behavior. Those three things will tell you everything.

Signal 1: How did it arrive?

Pull up your traffic graph for the last 30 minutes.

If volume jumped vertically, seconds to minutes, no ramp, that is attack-shaped. Real users don’t arrive all at once. Campaigns ramp. Crawlers pace. A vertical wall is your first red flag.

A gradual climb that correlates with a recognizable business trigger such as an email send, a press article, or a social post going wide is a marketing spike. Before you do anything else, check your campaign calendar and ask your marketing team if anything went live in the last two hours.

A steady, rhythmic cadence with no business trigger and no acceleration is crawler behavior. Crawlers work through queues.

If signals conflict later: Shape is your fastest first filter but not your most reliable one. Sophisticated attackers ramp traffic deliberately to avoid vertical-wall detection. If Signal 1 says organic but later signals say otherwise, trust the later signals.

Signal 2: Where is it coming from?

Open your traffic source breakdown, by country, ASN, and IP.

If you see traffic concentrated in regions you don’t normally serve, or a large volume originating from a single ASN or a small cluster of data center ASNs, that is not organic. Real users come from real ISPs, Comcast, Jio, BT, Verizon, spread across the geographies your product serves. If your product is a B2B SaaS with customers in the US and UK, your traffic should look like this:

Top ASNs during spike:

AS7922  Comcast         — 18% of requests
AS9121  Turk Telekom    — 12% of requests
AS5607  Sky UK          — 11% of requests
AS1273  Vodafone UK     — 9% of requests
AS55836 Reliance Jio    — 8% of requests

If the geographic mix matches your normal audience or the audience of the campaign that just went live that points to organic.

If you see this instead:

Top ASNs during spike:

AS14618 Amazon AWS    -  64% of requests
AS15169 Google Cloud    - 21% of requests
AS8075  Microsoft Azure - 11% of requests

That is not users. Data center ASNs dominating your traffic means the requests are coming from machines, not people. This points to either a crawler or an attack depending on what the other signals say.

If traffic is concentrated in a single country or region you do not normally serve, say, 70% from a geography that represents 2% of your normal user base, treat it as suspicious regardless of ASN.

Cross-reference: For cloud IP ranges, check against published lists from AWS, Google Cloud, and Azure. For known crawler IPs, cross-reference against published Googlebot, AhrefsBot, and Semrush IP ranges before drawing conclusions.

Signal 3: What are they hitting?

Check your endpoint breakdown and add a rate dimension to it. URL pattern alone is not enough. You need to know which URLs are being hit, in what sequence, and at what speed.

An attack pattern looks like this:

Endpoint hits (last 15 min):
/api/auth/login          - 14,200 requests -  avg 950 req/min
/api/auth/login          - from 3 unique IPs
/api/checkout            - 180 requests
/api/products            - 92 requests

One endpoint being hammered at machine speed from a small number of IPs with no surrounding user journey is not organic. Attackers target the endpoint that costs you the most to serve such as login, checkout, password reset, GraphQL, search. If that endpoint is absorbing 90% of the spike while everything else is flat, that is your signal.

An organic marketing spike looks like this:

Endpoint hits (last 15 min):
/blog/post-that-went-viral    - 4,100 requests
/                             - 2,800 requests
/pricing                      - 1,900 requests
/signup                       - 1,200 requests
/features                     - 980 requests

Traffic spreading across landing pages, product pages, and conversion flows in a pattern that reflects real navigation. Users arrive, explore, and move toward a goal.

A crawler looks like this:

Endpoint hits (last 15 min):
/sitemap.xml                  - 1,200 requests
/blog/                        - 980 requests
/blog/post-1                  - 940 requests
/blog/post-2                  - 935 requests
/blog/post-3                  - 928 requests

Systematic, sequential, following your site structure. Crawlers work through linked pages methodically. If your sitemap and internally linked pages are being hit in order at a consistent rate, that is a crawler following your architecture.

Rate matters: A single IP hitting login 950 times per minute is not a slow typist. Add rate per IP to your endpoint analysis before drawing conclusions from URL patterns alone.

Signal 4: Who is making the requests?

Check your user-agent breakdown and request header completeness. But read this signal carefully, it is the easiest one to fake.

A real browser leaves a full fingerprint:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/124.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Cookie: [session cookie present]
Referrer: https://twitter.com/

Full headers, cookie persistence, referrer from the traffic source, JavaScript execution happening in the background. This is a real user arriving from a social link.

An unsophisticated attack or basic scraper looks like this:

User-Agent: python-requests/2.28.1
Accept: */*
Accept-Encoding: gzip, deflate

[No cookies, no referrer, no Accept-Language]

Blank or minimal headers, no JavaScript execution, no cookie handling. This traffic is automated and not trying to hide it.

A declared crawler looks like this:

User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)

If the UA declares a known crawler, cross-reference the source IP against published crawler IP ranges. If the IP matches, it is legitimate. If it does not match:

User-Agent: Googlebot/2.1
Source IP: 45.83.192.14  ← not in Google's published IP range

That is a spoofed UA. Treat it as hostile.

The evasion caveat: Modern sophisticated bots execute JavaScript, set cookies, and mimic real browser fingerprints precisely. If Signal 4 looks clean but Signal 5 does not match, trust Signal 5. Behavior is harder to fake than headers.

Signal 5: Is the traffic doing anything?

This is your fastest and most reliable confirmation signal. Open your conversion and engagement data for the spike window.

Real users complete journeys. They sign up, purchase, start trials, add items to cart, spend time on page. If your traffic spike looks like this:

Spike window: 10:45pm — 11:15pm
Sessions:          +380%
Signups:           +340%
Trial starts:      +290%
Add-to-cart:       +310%
Average session time:   2m 14s  (baseline: 2m 08s)

Conversions rising proportionally with traffic, session time holding steady, this is real. This is your strongest single confirmation of an organic spike. Do not block anything. Call your marketing team.

If your traffic spike looks like this:

Spike window: 10:45pm — 11:15pm
Sessions:          +380%
Signups:           +1
Trial starts:       0
Add-to-cart:        0
Average session time:   0m 03s

Volume is high, conversions are zero, session time is near zero. Attackers do not buy your product. Bots do not fill out forms. This is your clearest signal that the traffic is not human. Act on it.

A crawler spike looks like this:

Spike window: 10:45pm — 11:15pm
Sessions:          +380%
Signups:            0
Page views per session: 1.0  (hitting single URLs, not navigating)
JavaScript events:  0
Avg session time:   0m 01s

No conversions, no navigation, no JS execution, one page per session. The traffic is reading your content and leaving. Not hostile, but worth rate limiting if it is affecting performance.

Putting it together, your classification

You don’t need all five signals to agree. In practice, three or four pointing the same direction is enough confidence to act.

What You See Most Likely Cause First Action
Vertical spike + one endpoint hammered + zero conversions DDoS attack Rate limit the hotspot, enable bot challenges, engage WAF provider
Gradual ramp + known trigger + conversions rising Marketing spike Scale carefully, protect expensive routes, keep monitoring
Steady cadence + datacenter ASNs + declared crawler UAs Legitimate crawler Verify identity, rate-limit if excessive, allow if confirmed legitimate
Steady or bursting + blank UAs + zero conversions + no known trigger Aggressive or malicious bot Challenge or block suspicious fingerprints, apply endpoint rate limits

Weighting rule: If signals conflict, weight them in this order: Signal 5 first, Signal 3 second, Signal 2 third, Signal 1 and Signal 4 last. Conversion data and endpoint rate are the hardest to fake. Shape and user agent are the easiest to manipulate.

If you have run through all five signals and you are still not certain, or if the classification is pointing to an active attack, do not wait. Every minute of unmitigated attack traffic is availability you are not getting back.

If you are under attack right now, Get expert eyes on your traffic right now. AppTrana’s 24×7 security team can help you classify the spike, confirm the threat, and stop the attack before it takes your site down.

Talk to an expert now

Indusface
Indusface

Indusface is a leading application security SaaS company that secures critical Web, Mobile, and API applications of 5000+ global customers using its award-winning fully managed platform that integrates web application scanner, web application firewall, DDoS & BOT Mitigation, CDN, and threat intelligence engine.

Frequently Asked Questions

Check three signals in order: first, conversion data are signups, purchases, or real sessions rising? Second, endpoint concentration, is one API route being hammered while the rest of the site is normal? Third, source diversity are IPs spread across consumer ISPs, or concentrated in data center ASNs or unexpected geographies? A marketing event typically produces rising conversions, broad endpoint distribution, and diverse organic sources. An attack produces zero conversions, endpoint concentration, and unusual source patterns.

Yes, and attackers know it. Timing a DDoS during a public launch or campaign is deliberate. The spike looks explainable, your team hesitates to block traffic, and the attack hides in the noise.

The tell is your conversion rate. A real marketing spike lifts traffic and conversions together. If volume surges but conversions stay flat, part of that traffic is not real.

Don’t choose between protecting availability and protecting conversions, a managed DDoS protection can suppress attack traffic surgically without touching legitimate users, even when both are arriving simultaneously.

Look at the user-agent strings and the IP origin. Aggressive crawlers even undeclared ones tend to originate from data center ASNs (AWS, GCP, Azure) and often hit navigable URLs rather than a single concentrated endpoint. DDoS traffic is more likely to be concentrated on one specific high-cost target and may come from residential botnet IPs or a wide range of ASNs. If the declared crawler user-agent does not match the actual IP range (for example, a request claiming to be Googlebot but originating from a non-Google IP), treat it as suspicious.

Attack traffic in application-layer floods often shows a sudden jump in request rate to one or two specific endpoints, with requests that do not follow normal session behavior no referrer chain, no session depth, no JavaScript events. Client fingerprints tend to be uniform (same user-agent string at unusual proportions, identical headers). Error rates climb as the application is overwhelmed. For volumetric attacks, the log volume itself can become the problem bandwidth to write logs may be saturated, making log collection incomplete during the peak.

No. Blocking all crawlers, including legitimate search engine bots, can hurt your SEO by preventing Googlebot from indexing your content. The right approach is to identify which crawlers are contributing to the load, verify their declared identity against known IP ranges, and rate-limit the ones creating excessive load rather than applying a blanket block. Most WAAP platforms allow granular rule creation that apply different handling to declared, verified crawlers versus undeclared automation.

Collect the following while the event is active: the start and peak timestamps and the time of each action you took; screenshots of traffic analytics showing requests per second, top endpoints, top source IPs and ASNs; a sample of access logs from the peak window; conversion metrics during the peak; screenshots of infrastructure metrics including bandwidth, CPU, connection counts, and error rates; and a note of what controls you applied and whether they helped. This evidence is useful for provider escalations, post-incident reviews, and improving your response the next time.