Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Bench Notes

API backend hosting — Your consumers experience the ninety-fifth percentile

An average response time hides the requests that time out inside somebody else's application, and those are precisely the ones that generate integration tickets.

The short answer

Business hosting carries a modest REST backend perfectly well; a VPS becomes the answer the moment you need latency you can guarantee, custom middleware or websockets. Our Boost VPS is where we would put an API with partners on it, because the four layers that decide the p95 — TLS handshake, request queueing, compute and the database round trip — are then all yours to configure.

What follows: which percentile to alert on, how to work out where a slow response actually spent its time, what breaks when you cannot set your own headers and timeouts, and how to design rate limiting before the first integration rather than after it.

By the HostingFast team · Reviewed 24 August 2026

99.9%

Uptime target we monitor

24/7

Humans on support, any hour

Free

SSL, issued and renewed

NVMe

Drives, entry tier included

Every response spends its latency budget in layers: TLS handshake, time queueing for a worker, your own compute, and the database round trip. Hosting decisions set the floor under all four before a single line of your code runs, which is why an API's performance conversation starts with the plan rather than with the framework.

The second thing to internalise is the distribution. Consumers do not experience your average; they experience whichever request their own timeout landed on. A backend with a respectable mean and an ugly tail generates a steady trickle of "your API is unreliable" reports that no dashboard showing averages will ever explain.

Measure the distribution, not the mean

Log the duration of every request in your application and aggregate it as percentiles. p50 tells you how it feels on a good day; p95 tells you what a partner's monitoring is seeing; p99 tells you what will page someone at three in the morning. Alert on p95 and investigate p99.

Then generate load deliberately rather than waiting for it. A short run at your realistic concurrency, against a real endpoint with a real payload, will show you where the tail starts to climb. Do it against staging, keep the numbers, and repeat it after every meaningful change.

Strict uptime matters here for a reason that is easy to underrate: an API failure propagates noisily through everything downstream, so a fault you would tolerate on a website becomes several partners' incident.

Find out where the time actually went

Split a slow response into its parts before optimising anything. curl's timing output gives you the handshake and the time to first byte from outside; your own instrumentation gives you compute and query time from inside. The gap between the two is queueing — requests waiting for a worker — which is a capacity signal rather than a code one.

Cheap wins usually live at the edges. Connection reuse removes repeated handshakes for a chatty consumer, and an index on the column your busiest endpoint filters by frequently removes more milliseconds than any plan upgrade would.

If the queueing component is the large one and the code is already lean, that is the moment the tier is genuinely the constraint.

Own the edge, or accept its defaults

Hosting an API somewhere you cannot set your own headers and timeouts turns every integration bug into an excavation. CORS behaviour, cache-control on responses, the read timeout, compression on JSON payloads and the TLS configuration are all things a consumer will eventually hit, and all things you want to change in a config file rather than in a support ticket.

Concretely, that is our Boost VPS option: full root on KVM virtualisation, DDoS filtering in front, snapshots on demand and one flat monthly rate, with in-place upgrades ready when the traffic grows.

Every plan ships with a free SSL certificate that renews itself ahead of expiry — the padlock is never something you have to remember.

Design the limits before the first partner

Rate limit at an edge you control — server rules or middleware on a VPS — then reinforce it with API keys and per-key quotas inside the application. Return 429 with a Retry-After header rather than dropping the connection, because a well-behaved client can back off correctly only if you tell it how long to wait.

Publish the limits in your documentation on day one. Retrofitting them later breaks working integrations, and the resulting conversation is considerably more expensive than the afternoon it would have cost to design them in.

A developer working against a hosted server over SSH

Latency is the product

For a JSON backend, the hosting decision is a latency decision and very little else. We would rather talk about percentiles and where the time goes than about how many gigabytes come with the plan.

Order an annual plan and the first year of your domain registration costs you nothing — useful when the API deserves its own hostname rather than a path on the marketing site.

  • Alert on p95, investigate p99
  • Split handshake, queue, compute and query
  • Full root, so headers and timeouts are yours
  • 429 with Retry-After, documented from day one

Why HostingFast

Standard on every plan

Root over the whole request path

Full root on KVM, so CORS, timeouts, compression and TLS are configuration rather than a support request.

DDoS filtering in front

Volumetric traffic is absorbed at the network edge before it reaches the process answering your consumers.

Snapshots before a risky deploy

Take one on demand, ship the change, and roll the whole machine back if the p95 goes the wrong way.

Predictable monthly cost

One flat rate rather than per-request billing, so a partner's retry storm is a capacity problem and not an invoice.

A company on the record

Vitalcare at Home Ltd, registered in England and Wales — worth confirming before partners depend on you.

A managed tier underneath

A modest internal API runs happily on Business hosting, so the VPS is a decision you make on evidence rather than on principle.

Quick Start

From order to online

  1. 1

    Instrument every request

    Log duration per endpoint and aggregate as percentiles. Without p95 you are optimising for a number nobody experiences.

  2. 2

    Attribute the slow ones

    Handshake, queue, compute, query. Fix the largest component; upgrading the wrong layer changes nothing measurable.

  3. 3

    Write the rate limits down

    Per-key quotas, 429 with Retry-After, published before the first integration rather than after it.

Built In

Loaded onto every plan

  • Money-back cover: 30 days on hosting plans, 7 on reseller
  • Human support on duty every hour of every day
  • In-place plan upgrades — no migration when you grow
  • Softaculous on board for one-click application installs
  • Free SSL that reissues itself well before expiry
  • Mailboxes running on your own domain name
  • Free migration carried out by our engineers
  • 99.9% uptime as the target, monitored around the clock
  • DDoS filtering absorbed out at the network edge
  • Full SSH with Git and Composer, not a restricted shell

Frequently Asked

What people ask us most often

Which percentile should I alert on?

p95 for alerts, p99 for investigation, p50 for context. An average is close to useless for an API because it is dominated by the fast majority and says nothing about the requests that tripped a consumer's timeout. If you can only instrument one thing, instrument per-endpoint duration and aggregate it into percentiles later.

How do I work out where a slow response spent its time?

Measure from both ends. curl's timing output gives you DNS, connect, TLS handshake and time to first byte from outside. Your own instrumentation gives you compute and query time from inside. Whatever is left over is queueing — requests waiting for a worker — and that is the component that indicates a capacity problem rather than a code one.

What actually breaks when I cannot set my own headers?

CORS is the first casualty: a preflight that needs a header you cannot add fails in the browser with a message that blames the wrong thing. After that come read timeouts, cache-control on responses, and compression on large JSON payloads. Every one of them is a five-second edit on a machine you control and an open-ended ticket on one you do not.

How do I change rate limits without breaking clients?

Version them the way you version the API. Announce the new limits, return 429 with a Retry-After that clients can honour, and run the old and new quotas side by side for a deprecation window. The failure mode to avoid is silently tightening a limit — integrations that were working start failing intermittently, which is the hardest kind of fault for a partner to diagnose.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Own the whole request path.

Root on KVM, DDoS filtering at the edge, snapshots on demand, and one flat monthly rate.

View VPS Hosting plans