Whose Traffic Decides How Long Customers Wait
Black Friday falls on November 27 this year, and the teams running online stores, support desks and booking apps are settling their hosting now, mostly by leaving it alone. For six kinds of customer-facing software that's probably a mistake. On a rented slice of a shared machine, a stranger's traffic helps decide how long a customer waits, and the usual cure is a dedicated server that one company controls from the operating system up.
Most apps don't need one. A brochure site or a small shop runs happily on shared cloud capacity and should stay there. The argument here is narrower, and it rests on a simple test. Full control of the server tends to earn its cost only when customers can feel what's happening underneath the app.
For anyone who doesn't live in a server room, most hosting sells a virtual machine, which is a software-defined share of a bigger computer that serves other customers too. A dedicated server is the bigger computer itself, rented whole.
Pages Where Customers Pay or Sign In
The first case is any page where a customer pays or signs in. Checkout and account pages are personal to each visitor, so they can't be handed out from a cache and every request waits on the server itself. Google's guidance on server response time calls a first byte good at 0.8 seconds or less and poor above 1.8, and it tells developers to look at hosting before they try anything else.
Hosting matters most on the one day nobody can afford a slow page. Virtual servers share a processor and disks with other tenants, and peak season is peak season for all of them. When the neighbor's sale goes live, your checkout can end up paying for it. Worse, the team usually can't see the cause, because the neighbor sits behind a wall that only the provider can look over.
That blind spot is what dedicated bare metal infrastructure removes. One customer rents the entire physical machine, with no virtualization layer and no other tenant on it, and holds root access to the operating system. If the checkout slows down on that hardware, the cause sits somewhere the team is allowed to look, and its engineers can go and find it.
Measurement comes before any contract, and it costs nothing. Check the first-byte time on the checkout itself, since a fast home page says little about a page that queries the database for every visitor. A response header called Server-Timing can report how long the database took on each request, which shows where the time goes before anyone commits to new hosting.
What the Research Says About Shared Hardware
The neighbor problem has been measured. When a University of Zurich study of two large public clouds put fifteen hypotheses about cloud performance to the test, it concluded that sharing hardware between tenants had a dramatic effect on performance and on how predictable that performance was. The paper is a decade old and isolation has likely improved since. Tenants still share processors and disks, though, so the cause hasn't gone anywhere.
Peak days make the problem sharper. Over the 2025 Black Friday weekend, merchants on Shopify took $14.6 billion, and just after noon Eastern time on the Friday their sales peaked at $5.1 million a minute. A single store's peak is far smaller but tends to have the same shape, with a few minutes carrying much more than their share of the year.
With the machine to itself, a team can give the database as much memory as it needs and match the web server's worker count to the real number of processor cores. A load test in October then predicts November, because the machine will be the same machine carrying nobody else's load. On shared hardware a clean load test may prove little more than that the neighbors were asleep at the time.
A few habits make that test worth trusting. Run it at the hour the sale will start, and judge it by the slowest five percent of requests, because an average hides the customers who gave up. Then size the server for last year's busiest minute plus whatever growth the marketing plan has promised, since that minute is what the hardware has to survive.
Voice Calls and the 150-Millisecond Budget
Voice comes second, and it's less forgiving than any web page. The United Nations telecom agency worked out decades ago how much delay a conversation can take, and its recommendation on one-way transmission time holds that speech feels natural while the delay from mouth to ear stays under 150 milliseconds. It tells network planners not to go past 400. Beyond that, the document's own word for the delay is unacceptable.
A call needs a steady server more than a fast one. Audio packets that arrive unevenly are held in a buffer and played out in order, and the buffer adds delay of its own. On a shared host, a processor lent to another tenant for a few milliseconds can be enough to make packets arrive late.
Network engineers put numbers on steadiness too. Cisco's long-standing design guidance for voice traffic aims for jitter under 30 milliseconds and packet loss of no more than 1 percent, and it reports lab tests in which call quality fell off sharply once jitter stayed above that mark. The same guide works out that a 1 percent loss rate means an audible gap roughly every three minutes of a call. Those figures make a usable acceptance test for any server that will carry calls.
When the Call Runs Through a Chat Widget
Plenty of businesses now offer voice calls straight from a website's chat widget, and a company running its own call servers hears every stutter of the machine relaying that audio. Shoppers will sigh and wait out a slow page, but a caller who can't make out the agent is likely to hang up, and the next call may well go to a competitor. Real-time audio is the workload where engineers tend to stop arguing about the monthly price and start asking who else is on the box.
For teams that do run their own calling, placement usually matters more than raw horsepower, so the media relay belongs on a machine that does nothing else, in the region where most callers live. Measure jitter at the agent's end as well as the server's, because a clean server and a bad office network produce the same complaint.
AI Assistants That Read Customer Conversations
Third come the AI assistants that read customer conversations, and most support teams are being told to deploy them. In a Gartner survey of 321 service leaders published this February, 91 percent said executives were pressing them to implement AI. Pressure like that favors whatever can be switched on fastest, which usually means sending conversations to somebody else's model.
The risk in that route showed up in 2025. A US court hearing a newspaper copyright lawsuit ordered OpenAI to keep chat and standard API content that it would normally have deleted within 30 days. The company's own account of that order says the obligation lasted until September 26, 2025, and that customers with zero-retention contracts were exempt.
Any support bot built on the standard service was sending customer messages to a vendor that had promised to delete them, and for months that promise was suspended by a dispute the bot's owner had no part in. Nobody in that chain did anything wrong, and the deletion schedule still turned out to belong to someone else.
Whose Disk Holds the Transcripts
An open model running on a server the company controls narrows that exposure to the company's own legal affairs. It also needs a machine with a graphics card nobody else is queuing for, which isn't cheap, and for a small team a zero-retention contract may be the saner route. But AI in live chat gets better as it sees more of each customer's history. The longer that history gets, the more it matters whose disk it sits on.
Whichever route a team picks, the same homework applies. Write down exactly which parts of a conversation reach the model, and strip card numbers and identity documents out before any of them do. Ask the vendor for its retention terms in writing, including what happens under a court order. A team that can't answer those points for its current bot has a data question to settle before it has a hosting one.
Regulated Records and the Auditor's Two Questions
Regulated records are the fourth case, and the easiest to argue. Card numbers and health details bring an auditor sooner or later, and auditors tend to ask where the data sits and who else shares the hardware. On a single-tenant server the second answer is no one, which takes a sentence to give instead of a diagram.
Single tenancy also changes what the company can see for itself. Every access log and every packet on the machine is its own to inspect, with no ticket to file and no wait while a provider decides what it's allowed to share. That matters on the day something goes wrong and a customer wants to know exactly what was touched.
Being the only tenant doesn't make anyone compliant, though. A badly patched dedicated server is arguably worse than a well-run shared one, and having the machine to itself only shortens the list of things a company must take on trust from its provider.
A one-page hosting note pays for itself here. It should say where each class of customer record is stored, who holds administrator access, how quickly security patches go on and how long logs are kept. Sales teams end up answering those questions in security questionnaires anyway, and an auditor is likely to start there.
Connections That Stay Open
Fifth is anything that holds a line open to each customer. Live order tracking and the typing previews familiar from how live chat works on a website both keep a connection alive per visitor, sometimes for hours. Ten thousand visitors means ten thousand open connections, and an operating system's default limits were never set with that in mind.
The engineers behind the Phoenix web framework documented in 2015 how low those defaults sit. Their first test stalled at about a thousand connections because the server's open-file limit was 1,024. After raising that limit and seven kernel settings, and after several fixes to their own code, they held two million open connections on a single machine with 40 cores and 128 gigabytes of memory.
Raising those limits means editing kernel settings, which takes root access and, on managed platforms, often takes permission the customer doesn't have. On a dedicated machine it's an afternoon's work. Nobody should rent a server for this reason alone, but teams that hit the ceiling tend to hit it during a launch, with the marketing emails already sent.
Ask whoever runs the servers what the open-file limit is on the machine that holds customer connections, then compare it with the largest number of simultaneous visitors the business has ever had. If the two numbers are close, the next successful campaign will probably find the limit before the team does.
Software That Expects Its Own Machine
The sixth case is the least glamorous. Some software simply expects its own machine, whether that's an older commerce platform pinned to one operating system version or a database licensed by the processor core. Managed platforms choose which versions they'll support and retire the old ones on their own calendar.
Those calendars are public, and they don't wait for anyone's sales season. The Node.js release table now lists version 20 as end of life, a status it reached this April, and hosted platforms typically set their own deadlines for dropping a retired version. The owner of a whole machine makes that call alone and can decide to change nothing until January. That freedom has a short shelf life, though, because a retired version stops receiving security fixes.
A version inventory turns a retirement date from a surprise into a plan. List every runtime, database and operating system the customer-facing app depends on, with the date each one loses support. Anything that expires between October and January deserves a decision now, while there's still time to test the upgrade.
What Full Control Costs
None of this is free, and the monthly rent is only the visible part of the bill. Full control means nobody else patches the operating system or watches the logs, unless the company pays its provider to manage the machine. One server is also a single point of failure until a second one sits beside it, and the second one doubles the rent.
Running the machine takes people as well. A team with no one comfortable at a command line will probably leave it unpatched and exposed, and its customers will be the ones who find out. Hiring that person, or paying for management, belongs in the price comparison from the first day.
Dedicated hardware doesn't stretch on demand either. Shared cloud capacity can grow within minutes during a surge, while a physical server grows when someone upgrades the hardware, and a new one has to be built and racked before it can serve anybody. So the machine has to be sized for the worst hour of the year. Any team that can't describe that hour in numbers probably isn't ready to rent one.
Nor does a dedicated server sit any closer to the customer. A shopper on another continent still waits on the distance, whoever owns the hardware, and a content delivery network in front of the server remains the answer to that. Dedicated hardware fixes what happens inside the machine. It does nothing about the ocean.
For many teams the sensible answer is a split. The few components that match one of the six cases, often the database and the call or chat servers, move to hardware the company controls. Everything that can be cached or restarted without a customer noticing stays on shared capacity, which keeps the bill and the patching workload in proportion to the part customers can feel.
A Test to Run Before November
Six is a short list on purpose. Anyone pitching a seventh case should be asked which customer would notice the difference, and if the answer is none, the shared plan was fine.
For teams that do recognize themselves in the six, there's a week of work that needs no purchase order. Start with the first-byte time on the checkout, because it's the number customers feel first. The open-file limit, the hosting note and the version inventory can follow in the same week. If two or more of the six cases turn up along the way, price a dedicated machine now and load-test it before the holiday code freeze, because that conversation is cheaper in October than during an incident.
Then run the check that needs no tools at all. Pull up the slowest hour from last year's peak and ask who in the room can explain it. If the best answer is that the platform was probably busy, then a stranger already helps decide how the company's customers get treated. Does anyone know which stranger?
