You open the dashboard, your GPU instance says Stopped, and you didn't stop it. That question, why did my GPU instance stop, used to have no good answer on most GPU clouds beyond "something happened." Spheron shipped three releases between 5 September and 5 November 2026 that turn that blank badge into a stated cause: who stopped it, what the provider actually did, and whether an in-progress operation is slow or genuinely stuck.
TL;DR: Reading an Instance's Timeline and Status Badge
An instance stops for a short, nameable list of reasons, and Spheron's dashboard now states which one applies instead of leaving you to guess.
- Status badges: v1.34.1 (27 Oct 2026) made badges hoverable, naming who stopped the instance: you, a price cap, Spheron, or a provider reclaim.
- Timeline tab: v1.34.2 (28 Oct 2026) added a sidebar tab listing every deploy, start, stop, restart, volume change, and failure, newest first.
- Spot price caps: on Spheron ES spot, a price above your max price auto-stops the instance and emails you, tagged
pauseInitiator: "price-cap"(v1.31.5, 13 Oct 2026). - Slow vs. stuck: a slow operation says "taking longer than usual"; one the provider never completed says "did not go through."
- Colors: Running is blue, Stopped is amber, Terminated is grey, per Spheron's lifecycle docs.
- A Stopped instance bills disk and IP only; see current GPU pricing to weigh Stop against Terminate.
Why Did My GPU Instance Stop? The Causes Behind a Stop
Before any of the dashboard work described below shipped, "stopped" was a single word covering at least five different situations, and you had no way to tell which one you were looking at. The causes themselves haven't changed; what changed is that Spheron now states which one applies.
The most ordinary cause is also the easiest to overlook: you or a teammate clicked Stop, intentionally, to pause billing on an instance you're coming back to. That's the behavior change Spheron shipped on 5 September 2026, where Stop keeps the disk instead of destroying it, so "stopped" by itself no longer tells you whether data survived, only the status badge and Timeline entry do.
Past that, three causes are specific to spot and automated behavior. On Spheron ES spot, if the market price for your GPU type rises above the max price you set, the instance stops itself and the account gets an email explaining why, with the deployment reporting status stopped and pauseInitiator: "price-cap", a behavior that shipped on 13 Oct 2026. Separately, the underlying provider can reclaim spot capacity out from under you with no price cap involved at all, a cause covered in more depth further down. And if you're redeploying the same broken configuration repeatedly, Spheron pauses the Deploy button on the account after several failed deploys in a short window, showing a countdown and the last failure's reason in the wizard; attempting to deploy during that pause returns a 429 with a Retry-After header, a safeguard that shipped on 28 Oct 2026.
The last common cause has nothing to do with the instance itself: running out of account balance destroys every instance on the account, stopped ones included, which is why Spheron's instance lifecycle docs state plainly that running out of credit forces a Stopped instance straight to Terminated. Stop pauses GPU billing; it doesn't pause the clock on your balance.
Spheron's own changelog describes the same distinction when covering the badge tooltip work: a Start the provider never confirms shows "Start did not go through," and a Stop the provider ignores shows "Stop did not go through."
That distinction matters because it draws the boundary this whole feature set is built around: a cause you triggered (you, a price cap, an account) is a different category from a cause the provider is responsible for (a reclaim, a stuck request), and conflating them into one grey "stopped" badge is what made this question unanswerable before late October 2026.
GPU Instance Lifecycle Status: The Timeline Tab Shows Every Deploy, Start, Stop and Volume Change
The Timeline tab is the part of this release that actually answers "what happened to this instance" rather than just "what is it doing right now." It sits in the instance sidebar next to Overview, added in v1.34.2 on 28 Oct 2026, and it lists the deploy, every start, every stop, every restart, every volume change, every failure, and the end, newest first.
This matters more than it sounds, because GPU instance lifecycle status isn't a single value you can poll once and trust. A status badge is a snapshot: it tells you what the instance is doing right now. A timeline is a sequence: it tells you how it got there. An instance that's Stopped right now could have gotten there through a deliberate Stop, a price-cap auto-stop, or a provider reclaim followed by a failed restart attempt, and those three histories look identical if all you have is the current badge. The Timeline tab is what separates them, because each entry in it carries its own cause the same way the badge tooltip does.
Practically, that makes the Timeline tab the first place to check before opening a support ticket. If an instance is Stopped and you don't remember stopping it, the Timeline entry for that stop will show whether it was pauseInitiator: "price-cap", a provider-side event, or an action taken from a different session under the same account. That's a five-second check that used to require asking support to pull logs on your behalf.
What Each Status Badge Actually Means
Spheron's instance lifecycle docs describe the badge colors directly: Running shows blue, Stopped shows amber, sitting between the running blue and the terminated grey, and Terminated shows grey. Color alone tells you the instance's category; the tooltip, live since v1.34.1 (27 Oct 2026), tells you why it's in that category.
| Badge | Color | What it means | What the tooltip adds |
|---|---|---|---|
| Running | Blue | GPU allocated, billing at the running rate | n/a, it's just running |
| Stopped | Amber | GPU released, disk (and IP, where charged) retained | Who stopped it: you, a price cap, Spheron, or a provider reclaim |
| Terminated | Grey | Instance and disk deleted for good | n/a, terminal state |
| Failed | (reason-specific) | Instance that never ran, shown as failed instead of terminated since v1.32.1 (16 Oct 2026) | The failure reason, and whether you were charged ("Not charged") |
| Starting / Stopping | In-progress | Operation underway, now stays visible until it resolves (v1.36.0, 5 Nov 2026) | "Taking longer than usual" or "did not go through" |
Two entries in that table are easy to confuse if you've only seen the color. A Terminated instance and its disk are gone; Spheron's guide to persistent storage covers the separate volume type that survives Terminate, which the instance's own bundled disk never does. A Stopped instance, by contrast, keeps that bundled disk in place on purpose, which is the entire point of the amber state sitting between the two.
Restart doesn't get its own badge at all. Per the lifecycle docs, the instance "keeps its status throughout" a restart, so the only way to tell a restart is in progress is the dedicated restart polling endpoint, which returns restarting: true with a timestamp for when it started. If you're watching the badge alone during a restart, it will look unchanged the whole time, which is expected, not a bug.
One more wrinkle worth knowing before you panic over a badge: a dedicated instance can briefly report as stopped or offline purely because the underlying provider rebooted its host. Since 14 Jul 2026, that instance stays running underneath and recovers on its own once the provider's host comes back online, no Start click required. If a dedicated instance flickers to stopped and self-corrects within a few minutes with no Timeline entry for an actual Stop action, that's almost certainly what happened.
Slow Starts and Stops: When "Still Working" Isn't a Failure
A Start that takes several minutes isn't automatically broken, and this is the part of the lifecycle that's easiest to misread if you're used to CPU instances booting in seconds. Spheron's late-October releases added explicit language for this: a slow Start or Stop now shows "Start is taking longer than usual" or "Stop is taking longer than usual," along with a reason, as of v1.34.2 (28 Oct 2026). As of the 5 Nov 2026 release, that Starting or Stopping state stays visible on the dashboard for the entire duration of the operation, including across a page refresh, rather than flipping back to a stale status the moment you reload.
The reason a Start can genuinely run long has nothing to do with Spheron's dashboard and everything to do with what has to happen before an engine will serve its first token. The point isn't the specific minutes, it's that a long Start is frequently an engine doing legitimate, fixable work, not a stuck dashboard.
Spot capacity adds a second wrinkle that looks like a stuck instance but isn't: a reclaim. From a caller's point of view, nothing looked stuck at all; from the instance list, the reclaimed node simply showed Stopped with a provider-reclaim cause in its tooltip. That's the gap this feature closes: without the badge naming the cause, a reclaimed spot node and a genuinely broken one look identical on the dashboard.
Spheron's instance lifecycle docs also note a 20-minute minimum runtime gate before you can manually terminate an instance, the default and adjustable by support, plus a separate rule that a provider's machine-type reservation is billed in full regardless of when you terminate early. Worth knowing before you Stop or Terminate a short-lived job expecting the clock to reset the moment you click.
What Happens When a Terminate Isn't Confirmed
Terminate is supposed to be unambiguous: the instance and its disk are gone, full stop, grey badge. The awkward case is when Spheron sends the terminate request and the provider doesn't confirm it went through. Before 28 Oct 2026, that gap had no clean representation; now the instance shows "Terminate not confirmed yet," and Spheron keeps retrying the request until the provider accepts it, rather than leaving the instance sitting in a state where you can't tell if it's really gone.
A related edge case runs the other direction. A deploy can fail on Spheron's side and later turn out to have actually started running on the provider's infrastructure anyway. Since the same 28 Oct 2026 release, that instance is billed from the moment Spheron finds it running, not from the original failed attempt, so a confusing deploy doesn't also become an overcharge. Between the unconfirmed-terminate retry and the correctly-dated billing on a late-discovered running instance, the pattern across this whole release cycle is the same: don't leave an ambiguous state unresolved, and don't let the user pay for the ambiguity either.
None of this replaces a push notification. There's no documented webhook for instance status changes today, so checking the badge or the Timeline tab is still something you do by visiting the dashboard yourself, not something that pages you. And Stop, and therefore most of this diagnostic layer, doesn't apply everywhere: Spheron MS bare metal supports neither Stop nor Start, so there's no amber state to diagnose there at all, only Terminated.
The same "state the cause instead of leaving a blank status" pattern showed up the same month at the container layer, not just the instance layer: Spheron Containers, launched 30 October 2026, runs its own Stop state independently of the instance it sits on, with the same cost-pause logic for GPU containers and none of it available for CPU containers, which only support restart or terminate. If you're debugging a container's status rather than a bare instance's, check that layer separately; the two don't share one badge.
A stopped instance you didn't stop isn't a mystery anymore, it's a tooltip and a Timeline entry away from an answer. Check the status badge and the Timeline tab on your next instance before assuming something broke.
Frequently Asked Questions
A handful of causes cover nearly every case. You or a teammate clicked Stop. On Spheron ES spot, the spot price rose above your set max price, so the instance stopped itself and the account got an email explaining why, with the deployment reporting pauseInitiator: 'price-cap'. The underlying provider reclaimed the spot capacity out from under you. Spheron paused the Deploy button on the account after several failed deploys in a short window, showing a countdown and the reason. Or the account ran out of balance, which destroys every instance, stopped ones included. Since 27 Oct 2026, hovering or focusing the status badge names which of these happened instead of leaving you to guess.
Stopped is the amber badge, sitting between the running blue and the terminated grey. It means the GPU has been released and billing dropped to the disk (and public IP, where the provider charges for one), not that anything was destroyed. A Failed badge is different: it marks an instance that never ran at all, shows its reason in a tooltip, and tells you in the sidebar whether you were charged, usually 'Not charged.'
As of Spheron's 5 Nov 2026 release, Stopping and Starting stay visible on the dashboard for as long as the operation actually runs, including after you refresh the page, rather than flipping back to a stale state. If it's genuinely slow, the badge says 'Start is taking longer than usual' or 'Stop is taking longer than usual' with a reason. If the provider never completed the request, it says 'Start did not go through' or 'Stop did not go through' instead, which is the signal that it's not just slow.
The instance shows 'Terminate not confirmed yet' and Spheron keeps retrying the request until the provider accepts it, rather than leaving the instance in an ambiguous state where you can't tell if it's gone or not. This shipped in the same 28 Oct 2026 release as the Timeline tab.
Not on a dedicated instance. If a provider reboots the underlying host, a dedicated instance can briefly report as stopped or offline, but it's still running underneath and recovers on its own once the provider's host comes back, a behavior Spheron shipped on 14 Jul 2026. You don't need to Start it yourself.
