On a marketplace built from other people's hardware, "uptime" is two jobs, not one. One belongs to the platform: the website, the API, the routing and billing in the middle. The other belongs to the provider: the actual GPU your job runs on. They fail in different ways, they're fixed by different people, and confusing them is how a renter ends up blaming the wrong party — or paying for downtime nobody was accountable for.
So it's worth being precise about where the line sits, and how each side is kept honest.
The platform's half: always-on, even mid-deploy
The part we control is expected to be there every second — including the seconds we're shipping a change to it. That's harder than it sounds. The naive way to deploy a service is to stop the old version and start the new one. For the couple of minutes it takes a model server to come back up, every request in flight gets an error. Ship twice a day and you've trained your users to expect a daily outage.
The fix is an old idea applied carefully: never run just one, and never restart them all at once. The pieces that serve traffic run as more than one identical instance behind a load balancer. A deploy is a rolling, blue-green change — the new version comes up alongside the old one, has to pass a health check before it takes any traffic, and only then does the old one drain and step aside. Repeat for the next instance. At every moment during the deploy, at least one healthy instance is answering.
The difference is not subtle. A single-instance redeploy of our inference tier put a roughly two-minute error window in front of everyone connected at that moment. The same change shipped through the rolling deploy produced zero failed requests — measured, not assumed. That gap is the whole reason the extra machinery exists.
There's a quieter trap on the same ground: restart one component and you can accidentally recreate everything that depends on it, which reopens the very window you were trying to close. The lesson is the same — reliability is mostly about not taking things down that didn't need to move.
None of this touches the GPU. It's the middle of the system — the part between you and the card. And it's ours.
The provider's half: the GPU, for the length of the rental
The card itself lives on a machine we don't own, in a room we've never seen, plugged into someone else's power and network. We verify it's real before it ever serves anyone — we benchmark every GPU rather than trusting its self-report — but verification is a snapshot. Uptime is a promise held over time, and that promise is the provider's.
Here's the important narrowing: we don't ask a provider to be online 24/7. A machine that sits idle and offline half the day costs no renter anything. What matters — the only thing that matters — is that once a machine is rented, it stays up and healthy for the length of that rental. Renting is the moment the provider makes a commitment on that hardware. Keeping it is their job.
That reframing is deliberate. It means a hobbyist with one 4090 they switch on in the evenings can be an excellent provider, as long as they don't yank the plug on a job someone paid for. Availability is cheap and gameable. Reliability under rental is the thing worth measuring.
How the line gets enforced: reputation
A rule nobody can see isn't a rule. So the provider's half of uptime is measured, scored, and shown to the next renter — through a reputation system built on one principle: judge the resource, not the renter.
Every finished rental is recorded and classified. Did the machine start promptly? Did it stay healthy the whole session, or did it go dark while a job was still running? Those roll into a rolling score for the machine, weighted so recent rentals matter more than old ones. Idle time is never part of it — the score is built only from real, completed rentals.
The principle does most of the work. If your job is what failed — an out-of-memory crash, a bad script, a process that exited with an error while the machine stayed online and healthy — that is not counted against the machine. It wasn't the provider's fault. Only a host failure — the machine dropping offline mid-rental, or never coming up — lowers the score, because that's the part of uptime the provider actually owns. Anything genuinely ambiguous is set aside rather than pinned on either side. A provider is never punished for a renter's mistake, and a renter never has to argue that a crash wasn't the machine's fault.
A machine's score, and a provider's
There are two scores, and the difference matters. One is tied to the individual machine. The other is tied to the provider's account, across every machine they run. The account-level score is the one that can't be shed: swapping a single piece of hardware in and out doesn't reset an operator's track record. The next renter sees both — how this specific card has behaved, and how the person behind it has behaved across their whole fleet.
Machines with too little history are shown as new — unproven, not bad. They carry their verified specs but no invented rating; reputation is earned, never faked. Machines with a solid record are proven, shown with their measured uptime while rented. And a machine with repeated host failures gets flagged, so renters can route around it. The market does the rest: reliable hardware earns the rentals.
Why it's built this way
Split responsibility cleanly and everyone can act on it. The platform can be held to a hard standard — always-on, zero-downtime deploys — because that part is fully ours to engineer. Providers can be held to a fair standard — keep the machine alive while it's earning — because that's the part they actually control, and they're judged on nothing else. And renters get the one thing a marketplace of strangers otherwise can't offer: a way to tell, before they spend a credit, which machine and which operator will still be there when the job is halfway done.
Uptime isn't one number. It's a line between two responsibilities, drawn on purpose — and measured on both sides of it.
Renting? Reputation & Uptime explains how to read a machine's score before you start. Running hardware? Set your own rental price and connect a machine at /become-provider.
FAQ
Who is responsible if a rented GPU goes down mid-job? The provider. Keeping a machine online and healthy for the duration of a rental is the provider's responsibility, and a host failure lowers that machine's reputation score. The platform is responsible for everything between you and the card — the API, routing and billing — which is engineered to stay available even during deploys.
Does my own crashed job hurt the GPU's score? No. Reputation judges the resource, not the renter. An out-of-memory error, a bad script, or a non-zero exit while the machine stayed online and healthy is not counted against the machine or the provider.
What is a blue-green (rolling) deployment? A way to ship a new version without downtime: the new version starts alongside the old one and must pass a health check before it receives traffic, then the old one drains. Because more than one instance runs behind a load balancer, at least one healthy instance is always answering — a redeploy interrupts no requests.
Does a provider have to keep their machine online all the time? No. Idle availability isn't scored at all. What's measured is uptime while rented — a provider only needs to honour the sessions they've actually taken on.
What's the difference between a node score and a provider score? The node score is for one specific machine. The provider score spans every machine that operator runs and is tied to their account, so it reflects their overall track record rather than a single card.
