Instance lifecycle
An instance does not have to be destroyed to stop costing you money. Stopping parks the machine: the GPU stops billing, the disk and everything on it stays exactly where it was, and you start it again when you need it. Restarting reboots a machine in place without changing what you are billed.
Neither action is available on every provider, and the two do not line up with each other. The dashboard shows each control only where the provider can honour it.
Stop, start, and restart compared
| Action | What happens | Billing | Data on disk | Public IP |
|---|---|---|---|---|
| Stop | GPU is released, instance is preserved | Drops to the stopped rate | Preserved | Retained |
| Start | Instance comes back on the same disk | Returns to the running rate | Preserved | Same address |
| Restart | Machine reboots in place | Unchanged | Preserved | Same address |
| Terminate | Instance and its disk are destroyed | Stops entirely | Lost | Released |
Stopping is about money. Restarting is about a machine that needs a reboot.
Provider support
| Provider | Stop and start | Restart |
|---|---|---|
| Spheron AI | Yes, depending on machine type and region | Yes |
| Spheron ES | Yes | No |
| Spheron MS | No | Yes, on virtual machines |
| Spheron AM | No | Yes |
| Massed Compute | No | Yes |
| Verda | No | No |
| Sesterce | No | No |
Restart is never synthesised from a stop followed by a start. That sequence releases the GPU and carries a completely different risk, so a provider without a real reboot operation does not offer the control at all.
Machine type and region limits on Spheron AI
Spheron AI stops an instance by hibernating it, and hibernation support varies by machine type rather than by GPU model. Roughly half the catalog cannot hibernate, and no spot machine type can. One region refuses to shut instances down at all, even though other regions on the same provider stop normally.
The deploy summary and the instance panel name which of the three limits applies, because the remedy differs each time:
- This machine type cannot be stopped. Pick another machine type from the same provider.
- Instances in this region cannot be stopped. Pick another region from the same provider.
- This provider does not support stopping. Pick another provider.
Check the note before you commit money to a deployment, not after.
Instances that never support either action
- Reserved instances. These are paid for off-app and administered by the Spheron team. Contact support to change one.
- Bare metal instances. A bare metal server has no hypervisor, so there is nothing to pause or reboot through.
What a stopped instance costs
A stopped instance is billed for its disk, not its GPU. The stopped rate comes from the provider and covers the retained disk plus the public IP where the provider charges for one. Any discount on your account applies exactly as it does while the instance runs.
Before you confirm a stop, the dialog quotes both rates, the saving as a percentage, a monthly figure for leaving the instance stopped, and an itemised list of what is still being charged. Stopped rates are shown to four decimal places, because at two decimal places most of them round to $0.00 and read as free.
Charges run on a five minute cycle. Stopping and starting both settle the elapsed time at the outgoing rate first, so a stop landing mid-cycle is not billed at the wrong rate for that slice. Usage figures and invoices pick stopped periods up with no change.
Starting again depends on stock
Some providers release the hardware while an instance is stopped, so a start can be refused while that machine type is out of stock. How likely that is depends on the provider:
- Spheron AI does not reserve the hardware during hibernation. A start can fail when the machine type is unavailable.
- Spheron ES keeps your quota occupied while the instance is stopped, so capacity is effectively held.
A refused start is not destructive. The instance and its disk stay exactly as they were, and you try again when stock returns. The stop dialog states the risk before you commit.
Restarting an instance
A restart is a hard reboot on every provider that offers it, so anything held in memory is lost. Write checkpoints and flush open files before you restart. The dashboard confirms before it proceeds.
Restart is available only on a running instance. Billing does not change, and the instance keeps its status throughout.
How a stopped instance appears in the dashboard
- The status badge is amber, between the running blue and the terminated grey.
- The card and the details panel both show the stopped rate, not the running rate.
- The public IP stays visible, so you do not have to start an instance to read the address back.
- The SSH command is hidden until the instance runs again, because it will not connect otherwise.
- Destroy stays available while the instance is stopped.
Minimum runtime is judged against time actually spent running, not wall time since deployment. Stopping an instance does not serve out its minimum runtime. See Minimum runtime before termination.
Minimum runtime before termination
An instance must run for a minimum period before you can terminate it manually. The default is 20 minutes, and two things can change the number that actually applies:
- The machine type. Some providers hold a machine for a minimum reservation and charge it in full whether or not you use the time. Where a machine type sets such a figure, it applies instead of the default when it is longer. It varies by machine type rather than by provider, so two configurations from the same provider can differ.
- Your account. Support can set a different minimum for an account, or waive it entirely.
The binding number is the larger of the two, and you never have to work it out. The deploy wizard names the provider and shows the figure before you deploy, and that is the same number enforced when you come to terminate.
Two rules follow from this:
- Read the figure before deploying a short job. Terminating early does not reduce a provider minimum, so a job shorter than the minimum costs the minimum.
- Stopping does not serve out the minimum. It counts time actually spent running, so an instance you stop after 5 minutes still owes the balance in running time before it can be terminated.
Through the API, call can-terminate before terminating. Its minimumRuntime is the number that applies to that specific deployment, so read it rather than assuming 20.
Lifecycle through the API
All five endpoints authenticate with your API key and act on a deployment you own or that belongs to your team.
Quote the cost of stopping
curl -X GET "https://app.spheron.ai/api/deployments/<deployment-id>/pause-quote" \
-H "Authorization: Bearer <your-api-key>"{
"hourlyRate": 0.0412,
"originalHourlyRate": 0.0412,
"currentHourlyRate": 2.45,
"breakdown": [
{ "label": "Root disk (512 GB)", "amount": 0.0362 },
{ "label": "Public IP (retained)", "amount": 0.005 }
]
}hourlyRate is what you pay while stopped, currentHourlyRate is what you pay now, and the quote changes nothing on its own.
Stop, start, and restart
# Stop the instance and drop to the stopped rate
curl -X POST "https://app.spheron.ai/api/deployments/<deployment-id>/pause" \
-H "Authorization: Bearer <your-api-key>"
# Start it again on the same disk
curl -X POST "https://app.spheron.ai/api/deployments/<deployment-id>/resume" \
-H "Authorization: Bearer <your-api-key>"
# Reboot in place
curl -X POST "https://app.spheron.ai/api/deployments/<deployment-id>/restart" \
-H "Authorization: Bearer <your-api-key>"Each returns the updated deployment object. Asking a provider for an action it cannot perform returns a refusal that names the limit rather than a generic failure.
Poll a restart in progress
curl -X GET "https://app.spheron.ai/api/deployments/<deployment-id>/reboot-status" \
-H "Authorization: Bearer <your-api-key>"{
"restarting": true,
"since": "2026-09-08T10:31:04Z"
}Find stopped instances
A stopped instance is part of the live set. ?status=active includes it alongside running and deploying instances, and ?status=stopped narrows to the stopped ones.
curl -X GET "https://app.spheron.ai/api/deployments?status=stopped" \
-H "Authorization: Bearer <your-api-key>"See the API reference for full request and response details.
Troubleshooting
Issue: The Stop button is missing
Symptoms: An instance shows Destroy but no Stop control.
Diagnosis: The provider, the machine type, or the region cannot stop an instance in a way that reduces the bill.
Resolution: Read the note in the instance panel. It names which of the three applies. Deploy on Spheron AI or Spheron ES if you need to stop instances, and check the deploy summary before committing.
Issue: Starting a stopped instance fails
Symptoms: The start request is refused with a capacity message.
Diagnosis: The provider released the hardware while the instance was stopped and the machine type is currently out of stock.
Resolution: Wait and try again. Nothing is lost. Set a stock notification for the machine type, or deploy on Spheron ES, which holds capacity while an instance is stopped.
Issue: A stop request times out
Symptoms: The request does not return before the client gives up.
Diagnosis: Writing a machine's memory to disk routinely outlives the request. A timeout usually means the work was accepted and is still running.
Resolution: Check the instance status again in a minute. The dashboard reports the settled state once the provider confirms it.
Issue: An instance was stopped without you asking
Symptoms: The instance reads as stopped and bills at the stopped rate.
Diagnosis: The provider parked the machine from its side.
Resolution: Start it again from the dashboard or the API. You are charged the stopped rate for the period it sat stopped, not the running rate.
What's next
- Instance types: Spot, Dedicated, Bare Metal, and CPU Node
- Regions and providers: Which provider supports which lifecycle action
- Cost optimization: Stop, resize, and reserve to cut spend
- Billing: How stopped periods appear in usage and invoices
- API reference: Lifecycle endpoint details