# The day the crowd arrives

> See what runs out first when a crowd arrives. Static and dedicated hosting fail differently, and you can rehearse before the day.

Source: https://customhosted.com/under-load/

№ 01 Under load

This page is about the traffic you wanted. A launch, a mention, or a good day can send more visitors at once than a steady climb ever would. Here is what runs out first, and how to find your own number before the day it matters.

№ 02 Two kinds of busy

## Two kinds of busy, and only one is a plan

Both of them are traffic you wanted. A third kind is not.

- A steady climb — More visitors, week over week, as the audience genuinely grows. There is time to watch it and plan a move.
- A spike that simply arrives — A launch, a mention, or a good day. The same traffic you wanted, arriving all at once instead of gradually.

Not this page

A volumetric flood

A sudden spike of requests aimed at knocking the site offline, not at reading it. Absorbed at the edge network, before it reaches a static site's storage or a dedicated instance.

This page assumes the traffic is real. Everything below is about a crowd that came to read you. [Under attack](https://customhosted.com/under-attack) owns the other half.

№ 03 What runs out first

## What runs out first

Transfer against a fixed allowance, then whatever Monitoring already watches for a capacity signal.

- Transfer — Counted against the plan's own fair-use allowance — Static Starter (~100 GB transfer/mo), Static Pro (~500 GB transfer/mo).
- Disk and memory headroom — Usage crossing a threshold set well ahead of the point it would actually cause an outage
- Connections, replication, and backup completion — A connection pool running out, replication falling behind, or a nightly backup that never reported success
- Queue liveness and scheduled-job completion — A queue backing up with nothing consuming it, or a scheduled job that starts but doesn't finish inside its window

№ 04 By hosting shape

## A static site and a dedicated instance fail differently

The fact this site has never published before this page.

- Static Static Pro — The edge network answers the crowd. Static Pro and its siblings have no server to queue behind — the only real limit is transfer, and transfer is priced flat.
- Dedicated Dedicated M — A single Dedicated M instance (2 vCPU · 2 GB RAM · 60 GB SSD · static IP) has a knee: it serves normally, then it queues, then a request waits long enough to fail. Two standing rules keep that knee where it is. A flat rate means fixed, known capacity. Nothing on this platform grows itself in the background and bills you for it afterwards. A single dedicated instance is one instance. Splitting a workload across more than one is a Custom quote, not a setting to switch on. Both rules are in § 10 as well.
- Custom Custom — A bespoke stack is sized to the workload at quote time, the same discipline as any other Custom shape.

№ 05 How many visitors is that, really

## How many visitors that allowance actually is

Derived from this site's own measured page weight — never a typed-in figure.

| Plan | Allowance | At the median page | At the heaviest page |
| --- | --- | --- | --- |
| Static Starter | ~100 GB transfer/mo | 6.1 million page views/mo | 2.9 million page views/mo |
| Static Pro | ~500 GB transfer/mo | 30.4 million page views/mo | 14.7 million page views/mo |

The median page here weighs 17.2 KB; the heaviest, /search, weighs 35.6 KB. Bytes only — one page per view, before images and fonts a real visit would also pull in.

№ 06 The rehearsal

## Find your own number before the day

A load test, run against staging, never production.

1. 1 — Ask for a rehearsal — Say what you expect — a launch date, an expected crowd size, or just "we want to know before we find out live". — You
2. 2 — A load test runs against staging — A second, standing copy of the same stack, built from the same infrastructure definition as production. Never production — nothing a real visitor would notice. — CustomHosted
3. 3 — The knee gets measured — The point where response times start climbing and errors start appearing, on this workload, on this tier — not a number copied from another customer. — CustomHosted
4. 4 — You get the number, and the causes — What the tier actually holds today, and what showed up first when it did not — see "what the rehearsal finds" below. — You

Around 45 minutes of your own time end to end — most of it waiting for a result, not doing the work yourself.

№ 07 What the rehearsal finds, and who fixes it

## Most causes are a code change, not a bigger box

Most of them are a change to the code. The rest are a rebuild. Each group is labelled below.

Cheaper than a bigger box

CodeHerder Each of these is a fix in the code. You brief it, it ships, and the invoice does not move.

- An unindexed query — A slow query run on every page load can look exactly like a compute shortage. Adding the missing index is usually a smaller fix than a bigger tier.
- An unresized image — Serving a large photo at a small width burns transfer and memory for no visible gain. Resizing it at build time often does more than moving up a tier would.
- A background job with no backoff — A job that retries immediately, over and over, can make the whole instance look short on room. Often the real fix is a short wait between retries.
- A cache that never gets used — Recomputing the same answer on every request costs headroom. Caching it once usually saves more than moving up a tier ever would.

When it's genuinely architecture

CustomLabs Each of these is a rebuild, not a briefed change. It is CustomLabs work, quoted on its own.

- A queue between two services — When one part of the app has to keep working while another catches up, that is a queue to design, not a bigger instance.
- A read replica — When read traffic alone is the bottleneck, a second database built for reads is a rebuild, not a resize.
- A second region — Running compute closer to a second cluster of users is a new deployment to design, not a tier to move up to.

Briefing a cause from "Cheaper than a bigger box" is what the Agentic iteration — CodeHerder ($25/mo) add-on covers. The steps below are what happens next.

1. 1 — The rehearsal names the cause — The load test returns the thing that gave way first. That is usually a slow query, an oversized image, or a job with no backoff. — CustomHosted
2. 2 — It's triaged as a code change, not a resize — A bigger tier hides a cause like that. A change to the code removes it. Only the cases under "When it's genuinely architecture" need a rebuild. — CustomHosted
3. 3 — Briefed as a change — Written up the same way any other change request is. The iteration add-on is what covers it. — CustomLabs
4. 4 — An agent opens the pull request — The fix lands as a real pull request against the repository, with the test suite run against it. — CodeHerder
5. 5 — A human reviews and merges — Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind. — CustomLabs
6. 6 — It ships through the same pipeline — The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit. — CustomHosted
7. 7 — You're told it's done — A note confirming what changed and that it merged, in the same shape as every other note on this site. — CustomHosted

№ 08 On the day

## On the day itself

The same watch, the same ladder, and the same rule about not throttling first.

| Tier | What counts | What happens first | Who hears |
| --- | --- | --- | --- |
| Auto-handled | A known, safe failure with an established fix — a crashed process, a failed health check, a stuck deploy | Restart, retry, or redeploy the last known-good version, done automatically | No one, unless it recurs — it goes in the log, not a message to you |
| You hear from us | Something that touched the app and needs a person to pick the right response, not just a retry | A human looks at it and decides what to do — revert, restore, or a fix in code | You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent |
| Outage handling | The site or a core function is down, or badly degraded, for real users | Worked ahead of the routine queue | You, as soon as there is something to say, with priority handling; out-of-hours response is best effort, not a staffed round-the-clock desk |

- No throttling as a first response — A workload getting close to its headroom gets a conversation, not a rate limit switched on quietly. We talk to you before anything changes.
- What an emergency move costs in minutes — Around 20 minutes of your own time, across the same 6 steps described on Scaling — scheduled where there's time to schedule it, done as fast as it can be where there isn't.
- What it does to the invoice — The rate is flat, up to the plan's posted fair-use transfer allowance. The allowances themselves are in § 05 above.

№ 09 This site's own numbers

## This site's own numbers, as the worked artifact

Every figure below is read from a measured build, not typed in by hand.

- **Routes measured**: 87
- **Routes shipping zero JavaScript**: 80 of 87, this page included
- **Median page weight**: 17.2 KB
- **Heaviest route**: /search, 35.6 KB

№ 10 The honest limits

## Said plainly

No requests-per-second promise, no uptime figure, and no "handles N users" claim.

- No published requests-per-second figure — How much one tier holds depends entirely on the app running on it. A number that ignored that would be true for nobody in particular — see the rehearsal above for how to find your own.
- No surge capacity held in reserve — Capacity does not appear on the day. A flat rate buys the headroom already sized into the tier, not a reserve that switches on when a crowd shows up.
- No queueing guarantee — A request that waits too long ends as an error handed back to the visitor, not a queue that holds it indefinitely.
- No autoscaling — A flat rate means fixed, known capacity. Nothing on this platform grows itself in the background and bills you for it afterwards.
- No load balancing across instances — A single dedicated instance is one instance. Splitting a workload across more than one is a Custom quote, not a setting to switch on.

№ 11 Answers

## Under load, answered

The questions that come up right before a launch date.

1. 01 Will my site survive going viral? A static site answers a crowd from the edge network, so the honest limit there is transfer, not requests. A dedicated instance has a knee — see "By hosting shape" above for what that means, and the rehearsal for finding yours.
2. 02 What happens on launch day if you have never seen my app under load? The same watching Monitoring already runs, plus the escalation ladder reused above. A rehearsal ahead of the day turns "we will see what happens" into a known number instead.
3. 03 Do you throttle us if traffic gets close to a limit? A workload getting close to its headroom gets a conversation, not a rate limit switched on quietly. We talk to you before anything changes.
4. 04 Does a traffic spike cost extra? The rate is flat, up to the plan's posted fair-use transfer allowance. A bot or scraper counts the same way — see Under attack for that half of the picture.
5. 05 Can you tell me how many concurrent users a tier holds? How much one tier holds depends entirely on the app running on it. A number that ignored that would be true for nobody in particular — see the rehearsal above for how to find your own.
6. 06 Can we test this before the actual day? Yes — that is what the rehearsal is for. It runs against the standing staging copy, never production, and comes back with the tier's own knee and the fixes it's cheapest to make first. Anything that turns out to be a code change is briefed and ships through the same pipeline as any other change — this is what the Agentic iteration — CodeHerder ($25/mo) add-on covers.

№ 12 Keep reading

## Under load connects to

- [Under attack The perimeter, and the volumetric-flood row § 02 quotes as the contrast — the kind of spike this page is not about.](https://customhosted.com/under-attack)
- [Scaling The move once a tier is outgrown — this page reuses its ladder, its move steps, and its honest limits whole.](https://customhosted.com/scaling)
- [Performance This site's own measured page weight, the number § 05 turns into a page-view figure.](https://customhosted.com/performance)
- [Billing The invoice, and the traffic-spike rule this page reuses whole in § 08.](https://customhosted.com/billing)
- [Monitoring The watch and the escalation ladder this page reuses whole in § 08.](https://customhosted.com/monitoring)
- [Environments The standing staging copy the rehearsal in § 06 runs against, never production.](https://customhosted.com/environments)

## Got a launch date and no idea what happens under real traffic?

Ask for a rehearsal through the same quote channel as any other request — a fix it turns up is Agentic iteration — CodeHerder ($25/mo) work once you're a customer.

[Get a quote →](https://customhosted.com/contact)