Skip to content
Appearance — System

Appearance

Light Dark System

Remembered across the site.

Managed infrastructure · a Stan Technology company

One person answers for your servers.

Dedicated servers, VPS, pipelines and AI hosting in British Columbia, managed by the operator who runs every other Stan Technology company on the same hardware. Write to us and the reply comes from the person who will be on the console.

Window 30 days · Bucket 15 min
Pins 11,520 · Ceiling 80% of capacity
Month peak — of ceiling
● now
3D Example
flood · cut at the edge regression · caught climbing

Beat 1 — the surface

Each pin is a quarter of an hour of resource usage. Its height is the busiest moment inside it — not the average of it. Averages are where downtime hides: a five-minute mean will swallow the ninety seconds that actually took your checkout down. You can only mind what you can see.

Beat 2 — the quiet hours

The amber is work we put where nobody is looking: backups, index rebuilds, vacuum and restore tests, log compaction. A trough is not wasted capacity, it is when the housekeeping gets done — and doing it at four in the morning is why it never competes with your customers at four in the afternoon.

Beat 3 — the capacity ceiling

The capacity ceiling is the line where we add hardware — eighty percent of what the machine can actually do, not a hundred. The last fifth is where latency goes strange and there is no time left to act, so we never plan to use it. Nothing on this page has reached the ceiling, and the room above it is yours to spike into.

Beat 4 — the two climbs

Red is what was taken away. The steep one was a flood from outside, cut flat at the edge before it reached the machine. The slow one came from inside — a query that stopped using its index — caught on the way up, not at the top. Neither ran us out of room: headroom is what buys the time to tell them apart.

resource usage scheduled work stopped now capacity ceiling

What one height leaves out

Capacity is not one number. A machine runs out of one thing at a time — and whichever goes first is the only one that matters that day. The field above collapses all of it into a single height so it can be read at a glance. What we actually watch is each of these on its own, and the ceiling is drawn against whichever is nearest its own limit:

CPU & steal time memory pressure NVMe throughput IOPS & queue depth GPU & VRAM bandwidth packets per second connection state edge router capacity database connections file descriptors inodes power per rack thermal headroom

Two things the picture also hides, both of which make the real ceiling lower than the drawing suggests. It is set for the machine that is not there: the line assumes a node has already failed and the others are carrying its work. And a flood is rarely about volume — it is usually packets per second or connection state exhausting a router long before bandwidth does, which is why it gets stopped at the edge rather than on your server.

Where the real numbers live

A drawing of your own uptime, made by the people selling you the uptime, is worth exactly nothing. So this section does not try to be one.

This is the example

The field shows how capacity gets handled on a production system: the shape of a working month, the line where hardware is added, the two kinds of climb and what happens to each of them. The numbers generating it are synthetic and change on every reload — that is deliberate, because the argument is the method, not the month. Nothing here claims to be a measurement.

This is the evidence

The live numbers get their own address: a status page with a monitor on each platform, published on Better Stack's own domain rather than ours. Uptime and every incident, written by the monitoring instead of by us — and kept on a host we do not control, so it is not ours to edit. If the two ever disagree, believe that page.

stanserve.betteruptime.com ↗

The way we build a platform

NVMe-only
storage, everywhere

no spinning rust in the hot path

5 services
one accountable operator

and one bill, via Stan Billing

0%
markup on AI tokens

flat fees, never a percentage

Against the hyperscaler

The cloud, without the fog

A hyperscaler console

  • Two hundred products, none of them a person
  • A bill that needs its own analyst
  • Egress fees that punish leaving
  • Your workload lives "in a region"

StanServe

  • A person who knows your stack by name
  • Flat USD pricing you can read at a glance
  • Transfer included, honestly sized
  • Your workload lives on a machine we can point to

Start

Tell us what you need to run.

A workload, an app, a fleet of agents — describe it and get a straight answer on what it needs and what running it well costs.