At 9:04 a.m., a newsletter with far more subscribers than your entire customer base hits send, and your product is in the third paragraph. By 9:20, more people have signed up than on any full day last month. By 9:40, the dashboard shows roughly twenty times a normal morning's traffic — and instead of celebrating, you are staring at a column of request timeouts, refreshing a page that is itself getting slower, watching the best morning of your company's life turn into a public problem. A note on the numbers: this scene is a composite illustration — the details are invented, but the shape is one solo founders describe the same way every time. The mention is real. The spike is real. So is the part where nobody is coming to help.
Key Facts
The Kill Chain: How Things Break Under a SaaS Traffic Spike: Almost every spike outage follows the same sequence; it deserves a name, so call it the kill chain.
The First 30 Minutes: A Triage Ladder, Not a Scramble: The first half hour decides most of the day, and it is the half hour where adrenaline makes its worst suggestions.
Fast Levers That Require No Code: With the ladder behind you, the picture is clear enough to act on.
Levers That Need a Small Deploy: Some relief requires shipping something.
Here is the reframe that changes how the day goes: the spike is not the emergency. The spike is the goal — it is compressed proof that something you built wants to exist. What turns a great day into a bad one is not the crowd; it is the outage that follows when the crowd meets an application sized for a quiet Tuesday. And that failure is surprisingly predictable. Small SaaS applications rarely fall over in exotic ways under load. They fall over in the same order, for the same reasons, almost every time — which means the right response can be written down in advance instead of improvised at 9:41.
So this is that response, written down: what to do when your SaaS gets a traffic spike. Below: the order things break, a triage ladder for the first 30 minutes, levers you can pull without writing code, the small deploys that buy breathing room, and the retro and capacity basics that turn one spike into preparation for the next. The promise underneath the whole guide is short: a spike is the goal. The outage after it is optional.
The Kill Chain: How Things Break Under a SaaS Traffic Spike
Almost every spike outage follows the same sequence; it deserves a name, so call it the kill chain. Learning it matters because each stage responds to a different lever, and pulling the wrong lever for your stage spends the minutes you do not have.
Stage one: the database connection pool runs dry
Every request your app serves needs a database connection, and connections are finite: your application keeps a small pool of them, and under normal traffic a connection is borrowed for a millisecond and returned. Under a spike, requests arrive faster than connections come back. A queue forms in front of the pool, and every request behind it slows down together. Nothing is broken yet. It is arithmetic.
Stage two: workers and memory saturate
Requests waiting on the database are requests your application workers are still holding, and held requests hold memory. Memory climbs toward the ceiling of each instance, workers serve fewer requests per second, and if the trend continues, your platform kills or restarts processes for crossing a memory limit — dropping every request those workers held. The slowdown is now structural.
Stage three: timeouts trigger retries, and retries amplify
Slowness becomes absence: browsers, mobile apps, and client libraries stop waiting and report a timeout. And here is the sentence that explains most spike outages: retries amplify the failure, because every timed-out request that a browser or background job fires again lands on the exact system that just failed to answer it — so effective load roughly doubles at the moment the system can least afford it. If your health checks start timing out too, the platform may restart instances on top of everything else, adding cold starts to the pile.
Read the chain backwards and you get your strategy: relieve the pool, protect the workers, break the retry loop. Everything in the next three sections is one of those three moves.
The First 30 Minutes: A Triage Ladder, Not a Scramble
The first half hour decides most of the day, and it is the half hour where adrenaline makes its worst suggestions. Run a ladder instead:
- Stay calm, and touch nothing for five minutes. Not five minutes of nothing — five minutes of watching. Request rate, error rate, and response times, on one screen. Spikes come in shapes: some are walls that keep climbing, some are humps that crest on their own. The most expensive early move in either case is a panic restart or redeploy that adds a second incident to the first. What you are building is the one thing the next 25 minutes require: an accurate picture.
- Confirm what is actually slow versus actually down. Open the product in a fresh incognito session and use it like a customer: land, sign up with a test account, run the core action. You are placing yourself in one of three states. Slow but working means queueing — treatable, survivable. Partially down means one route or feature is failing while the rest copes — isolatable. Fully down means the money path is failing fast, and your priority shifts from relieving load to degrading loudly and honestly. While you are in here, rule out the causes that are not traffic: a deploy that shipped at 8:50 can share symptoms with a spike, and if you run on a managed platform, its public status page answers "is this even mine?" in one visit.
- Shed optional load — deliberately. The money path is signup, login, the core feature, and billing. Everything else is optional for the next hour, and naming that list is half the value of doing this exercise before you need it. The usual first candidates: pause non-critical background jobs — nightly reports, digest emails, reindexing, cleanup sweeps — because they compete for the same workers and connections as live customers. Turn off heavy dashboard widgets: per-user analytics aggregates, expensive counters, anything that runs a real query on every page view. Queue signup emails instead of sending them inline: the welcome email can go out at 2 p.m., but a signup that times out at 9:40 may never happen at all. Shedding load is not admitting failure; it is choosing which requests get the remaining capacity.
- Do not redeploy during the spike unless the deploy is the fix. A deploy restarts workers, drops connections, and introduces a new variable into a system already holding more variables than it can explain — and under adrenaline, it skips review too. The exception is real: if the spike exposed an actual bug, a connection leak or a runaway query, and you have a small verified fix, ship it through the same health-gated path as any other release. That is a decision made on evidence. Redeploying "to be safe" is a reflex, and reflexes are what the ladder exists to prevent.
- Communicate if it is customer-visible. If people are experiencing slowness or errors, a two-sentence note beats an hour of silence: what is happening ("we're seeing far more traffic than usual"), what you are doing ("we're adding capacity and pausing some non-essential features"), and when you will update ("next update at 11:00"). Commit to a time, never to a fix time. The people inside your spike are your most engaged users; silence is how they become ex-users.
Thirty disciplined minutes usually lands you in "slow but standing," which on spike day is winning. Now you can pull levers instead of fighting fires.
Fast Levers That Require No Code
With the ladder behind you, the picture is clear enough to act on. These levers need configuration and a few clicks, not commits — which means they can happen at 9:45.
Scale instance size or count — if your setup allows it. On a managed platform this is often a size selector or a replica count; on a single VPS it means upgrading a box and probably rebooting it, which is its own short outage — do it only once you have confirmed the choke is CPU, memory, or worker count. The check matters because of the kill chain: if the bottleneck is database connections, more app instances make things worse, because every new instance brings its own pool and knocks on the same database door more often. Scaling fixes worker saturation; it can aggravate pool exhaustion.
Raise connection limits — only if the database can take it. When the pool is full, the tempting move is a bigger pool. The full pool math — instances times per-process connections, set against the database's own maximum, with headroom — is a topic of its own for a calm day. The spike-day rule is one-directional: never raise the application side without confirming the database side has room. A limit raised past what the database can actually serve does not remove the queue; it moves it inside the database, where every request pays for it and nothing else works either.
Enable queueing instead of dropping. When demand exceeds capacity, the excess has two possible fates: dropped or lined up. Dropping is an illusion — a timed-out request is usually retried, as stage three showed, so rejected load comes back doubled. Queueing converts the spike into a delay: signups accepted and processed in order, welcome emails held for a calm hour, reports waiting for the evening. A person in a slow line is still your customer. A person holding a timeout error is usually someone else's.
Lever
Helps when
Backfires when
Scale instances up or out
Workers or memory are the choke
Database connections are the choke
Raise connection limits
Pool is full and the database has idle headroom
Database is already near its own maximum
Queue instead of drop
Work is deferrable: emails, reports, imports
Request must answer synchronously: login, checkout
Notice what all three levers have in common: each is correct only for a particular stage of the kill chain. That is why "confirm what is actually happening" is step two of the ladder, not a formality — the diagnosis decides the lever.
Levers That Need a Small Deploy
Some relief requires shipping something. Ideally you built these switches on a calm day; if you are building them at 10:30 instead, keep each one small enough to verify in minutes.
- A static welcome or status page. On many small SaaS products the marketing site and the app share infrastructure, which means the crowd melts the front door at the same time as the house. A static page — "we're at capacity, signups are queued, here's what's happening, next update at noon" — served from plumbing that cannot fall over keeps the front door open and gives you the communication venue that step five of the ladder asked for.
- A read-only or feature-off mode for heavy features. Exports, reports, and heavy dashboards are usually the most expensive things your app does per request, and they are almost never what people came for during the spike. A flag that turns them off — with a "temporarily paused" message — frees workers and connections for the money path. The flag flips in seconds; the alternative, watching every user's report request hold a connection for thirty seconds each, is how one popular feature becomes the outage.
- Deferred expensive work. Pausing background jobs in the ladder was the operational version; this is the product version. Make the app stop offering heavy work it cannot currently serve: "Reports are delayed today and will run tonight" is a better answer than a spinner, and infinitely better than a timeout.
Each of these is a deliberate degradation: you chose what bends, and you said so out loud. Hold that thought — choosing the shape of the failure is the whole game, and it returns in the honest-limits section below.
When It's Calm Again: The Spike Retro
By mid-afternoon the curve settles, the queues drain, and you get the strange quiet of a day that could have ended the company and instead made its month. The spike retro is how the day pays rent twice: thirty to forty-five minutes, within 24 hours, one page, blameless. Three questions:
- Where was the first bottleneck? Not the loudest — the first. Whatever started queueing at 9:07 set off everything after it; the timeouts at 9:40 were a symptom with a timestamp. Fix the first bottleneck and the whole chain moves right. Fix only the loud parts, and the next spike breaks in the same place.
- What did you touch at 9:40 that should be a switch? Every manual action you took under adrenaline — killing a worker, pausing a cron, shutting a widget off, muting a report — is evidence of a switch that did not exist. List them. Each one is a small, calm-day deploy: a flag, a queue, an off-button. The goal is that next time, the shed-order list is toggles instead of heroics.
- Which alerts were missing? Answer honestly: how did you first learn the spike was hurting people? If the answer is a customer message, a social mention, or a friend's text, the honest finding is that you had no alert — and for a first spike, "yes, plural" is the expected result.
Then turn the day's observations into next-spike additions, signal by signal:
Signal
What it told you
What to add before the next spike
Latency climbed while CPU stayed flat
The choke is not compute — connections, locks, or I/O
An alert on database connection utilization, not just host CPU
First money-path timeout came 15 minutes after traffic peaked
A slow-burn queue with no early warning
A p95-per-route alert against your normal band, not just error counts
Welcome emails 400 deep at 10:00
Optional load was competing with signups
A separate queue with a shed switch for non-critical jobs
Marketing site slowed down with the app
The front door shared the app's fate
A static welcome/status page on independent plumbing
First report of trouble came from a user
Nothing was watching from the outside
An external uptime check on signup and login
Five rows like that are a whole quarter of infrastructure work for a company of one or two — and every row came from evidence you already paid for.
Capacity Basics: Know Your Normal Before the Next Crowd
You cannot judge a spike you have not measured against normal, so most spike preparation is really knowing your own numbers.
Know your normal p95. p95 is the response time your slowest one-in-twenty requests experiences, and it is the honest storyteller of load — averages hide the queue, p95 is the queue. Capture it for your top routes during a calm week and write it down. "Normal p95 on signup is 400 ms" turns spike-day "it feels slow" into "signup p95 is 2.1 seconds — five times normal, that is queueing," which is a diagnosis rather than a mood.
Load-test the top three routes once. Not a performance-engineering program — an afternoon. Pick signup, login, and your core action, drive a few times normal traffic against a staging copy or a quiet window, and watch which stage of the kill chain shows up first. You are not buying a number to put on a landing page; you are learning the name of your first bottleneck before it introduces itself at 9:40. One safety rule: load-testing the production machine your customers are using is its own incident waiting to happen — test somewhere disposable.
Keep a one-page spike runbook. The triage ladder from this article, your shed-order list, the levers table with the "backfires when" column made true for your stack, the status-note template with a blank for the next-update time. One page, because page two does not exist at 9:05 a.m. with adrenaline. This runbook is the artifact that turns everything else in this guide from reading into readiness.
The Honest Limits: Some Spikes You Cannot Out-Prepare
Everything above has limits, and pretending otherwise is the kind of optimism that outages feed on.
Some spikes cannot be out-prepared. A hundredfold viral moment — the entire internet arriving at once — will hurt no matter what you sized, and no ladder prevents it. At that scale you are not preventing degradation; you are choosing it, which is exactly why the preparation matters: the goal becomes graceful degradation. Decide in advance what gets slow, what gets queued, and what gets turned off, so the failure has a shape you chose. Slow but up beats down, almost always: a prospective customer who waits forty seconds for the signup page and gets in is still a customer; one who meets a timeout error is usually gone. And the queue is your friend here too — "you're in line, we'll email you" keeps the crowd counted even when it cannot be served.
Two more honest notes. First, the spike has a hangover: retry backlogs to absorb, queues to drain, background jobs piled three deep, caches to warm. Budget the morning after, too. Second, a spike is data, not destiny — before you permanently resize your infrastructure for a Tuesday that happens once, check whether the traffic ever came back.
Where a Platform Carries Some of the Weight
None of this requires a particular platform — the ladder, the levers, and the retro are discipline, not tooling. But spike day gets materially easier when the mechanical parts of shipping and observing are short, and this is where running your SaaS on Deployxa earns its keep:
- Per-deployment logs and metrics. "Which stage of the kill chain am I in?" is a logs-and-metrics question, and on Deployxa both are visible per deployment from the dashboard — so the 9:07 diagnosis is a click, not an SSH archaeology session.
- Health-gated deploys for spike-day fixes. If a fix genuinely needs to ship mid-spike, it rides the same gate as every other release: Deployxa's blue/green process puts the new version in a standby slot, verifies health, then switches traffic — so a rushed fix that cannot pass its health checks never reaches the crowd.
- A warm rollback window if the fix misbehaves. The prior healthy release stays warm for a short rollback window, so a spike-day hotfix that behaves badly under real load can be rolled back from the dashboard in seconds — the difference between a bad hour and a bad day.
- A platform-side answer to "is this even mine?" When latency climbs for a reason that is not yours, Deployxa's public status page at deployxa.com/status rules a platform incident in or out before you spend spike minutes debugging someone else's outage.
Honest limits, because spike day deserves them: the platform shortens the mechanical path; it does not make the judgments. Sizing your instances, deciding what queues and what must answer instantly, writing the degradation logic, defining what "optional load" means in your product — those are application decisions, and no dashboard makes them for you. Rollback reverses code, not data. And the docs cannot read your traffic for you either: the runbook is still yours to write.
The Spike-Readiness Checklist
Run this list against your operation today — every unchecked box is a finding for the next retro:
- [ ] Normal p95 captured for signup, login, and your core route, and written down
- [ ] Your last slowdown (or load test) mapped to a stage of the kill chain
- [ ] Shed-order list written: what turns off first, second, third
- [ ] Every non-critical background job has a documented way to pause it
- [ ] Heavy dashboard widgets and per-request expensive queries identified
- [ ] Signup emails queue instead of sending inline
- [ ] A static welcome/status page exists on plumbing that cannot fall over
- [ ] Your heaviest feature has an off-flag with a customer-friendly message
- [ ] Alerts exist for p95-per-route and connection utilization, and each has fired once on purpose
- [ ] The one-page spike runbook is written, pinned where you will actually be, and reviewed this quarter
Your Next Step: Write the One-Page Spike Runbook This Week
Everything in this guide works because it was written down before it was needed, and the one failure mode no article can fix is reading it for the first time during the spike. So here is the move, and it is an operations move, not a marketing one: block 30 minutes this week and write your one-page spike runbook. Fill in your normal p95 numbers for the top three routes, the shed-order list for your actual product, the levers table with the "backfires when" column made true for your stack, and the two-sentence status note with a blank for the next-update time. Then, if your product is already live, spend one more half hour rehearsing a single lever — pause a background job, flip a heavy feature off, watch it come back — so the runbook describes a machine you have actually touched. And if you want the mechanical half already in place before the crowd arrives — health-gated deploys, per-deployment logs and metrics, a warm rollback window, dashboard scaling — a non-production Deployxa project is the safe place to rehearse the whole spike before it is real. The founders whose spike days look calm are not calmer than you. They just wrote the page on a quiet afternoon — and at 9:05, they were reading it instead of writing it.