Auto-stop and auto-destroy
Two balance thresholds trigger automatic action on your instances. The first one protects your money. The second one deletes your data.
| Balance | What happens | Your disks |
|---|---|---|
| reaches ¥0 | Every running instance in the organization is stopped; where the machine supports it, its GPUs are released | kept, and still billed |
| has been at or below ¥0 for 24 hours and is at or below −¥35 | Every stopped or errored instance is destroyed | deleted permanently |
A running instance is never destroyed directly: at ¥0 it is stopped, and only a stopped instance can be auto-destroyed later.
There is no snapshot, no trash and no way to recover the contents once it runs. The 24 hours are a grace period to top up in, not a backup. Keep the balance above zero, and top up immediately if it goes negative.
How a balance goes negative at all
Charges are settled after the usage happens, about once a minute. A running instance can therefore consume up to roughly one more minute of GPU time after the balance crosses zero, before the settlement pass sees it and stops it.
From then on the descent is driven by storage. Stopped instances keep billing for their disks whether or not there are credits to pay for it, so a zero balance does not freeze the meter — it keeps falling toward −¥35.
At ¥0: auto-stop
When the settlement pass finds an organization at zero or below:
- Every instance in the
runningstate is stopped: the container shuts down and the disk is kept. Unlike your own stop, this one releases the GPUs back to the marketplace where the machine supports it. - Stopped instances whose GPUs are still held for you (the ones you stopped yourself) have their GPUs released too, where the machine supports it. This is recorded in the usage log as
instance.auto_released, shown as GPUs auto-released. - GPU charges end. Storage charges continue, at disk size multiplied by the storage rate per GB-hour.
- Deploying a new instance and starting a stopped one both fail with
INSUFFICIENT_BALANCEuntil you top up — and the top-up has to cover one hour of everything the organization would then be running, not just lift the balance back above zero. - The action is recorded in the organization's usage log as
instance.auto_stopped. - The 24-hour clock for auto-destroy starts.
Instances that were mid-transition — creating, starting — are not touched at that moment; a later pass stops them once they reach running.
Nothing restarts on its own after a top-up. Auto-stopped instances stay stopped until you start them from the console or the API.
After the GPUs are released
The disk stays on the same machine and is billed as storage while the instance is stopped. The instance page says GPUs released. A later start has to take back the same GPUs on the same machine. If they are free, the instance starts as usual. If they are in use by someone else, or out of service on that machine, the start fails in one of two ways. Either the request itself fails with 409 CAPACITY_UNAVAILABLE, and the console says "The GPUs this instance used are in use by someone else right now, so it can’t start. It’s still stopped with its disk — try again later." Or the platform accepts the start and the machine refuses it afterwards: the instance goes to starting and back to stopped, and the instance page shows the explanation for gpus_unavailable under The last action did not complete.
Either way the instance stays stopped with its disk intact, but nothing can reach the disk until a start succeeds: SSH and JupyterLab need a running instance. Start it again later. Destroy it only if you no longer need the data, because destroying deletes the disk; if the start keeps failing, destroying it and deploying again is the only way forward. To keep a copy of your data, copy it off while the instance is still running, before the balance runs out; see Stop vs destroy.
GPUs cannot always be released. A virtual machine (vm launch mode) never releases them, and neither does a machine that does not support release yet or that already keeps too many instances with released GPUs. Then the GPUs stay reserved for you, just as after your own stop, and you pay storage only while the instance is stopped. GPUs auto-released in the usage log records the platform's attempt; for as long as the balance still falls short, the platform tries again every 6 hours and logs another entry each time.
After 24 hours, at −¥35: auto-destroy
Auto-destroy runs only when both of these hold:
- the balance is at or below −¥35;
- it has stayed at or below ¥0 for at least 24 hours without a break.
It then destroys every stopped and error instance in the organization. For each one:
- The container and the disk are removed. Everything on that disk is deleted, permanently.
- The GPU slot is released back to the marketplace once teardown finishes, and can be rented by someone else.
- All charges for that instance end.
- The action is recorded in the usage log as
instance.auto_destroyed.
Instances still running are stopped, not destroyed; the next pass can destroy them once they are stopped. Instances that are mid-transition are picked up by a later pass once they settle.
Destroyed instances cannot be restored by topping up afterward. Credits added later apply to new work only.
Topping up stops both actions
Each settlement pass re-reads the balance immediately before it acts on an instance. If your payment lands first, the enforcement step is skipped and nothing is stopped or destroyed. Credits are applied as soon as the provider confirms the payment. A top-up that lifts the balance above zero also resets the 24-hour clock: if it goes negative again later, the grace period starts over.
A top-up that leaves the balance at or below ¥0 does not reset the clock. It only keeps the balance above −¥35 for longer.
How to never reach the second threshold
Destroy what you are finished with. A stopped instance you have no plans for is a debt clock. Copy anything you need off it, then destroy it. See Stop vs destroy.
Do the storage arithmetic before you walk away. Multiply your disk size by the storage rate shown on the offer to get the hourly cost while stopped; divide ¥35 by that, and you have the hours it takes the balance to fall from ¥0 to −¥35:
hours = ¥35 ÷ (disk GB × storage rate per GB-hour)
The table below uses an illustrative rate of ¥0.002 per GB-hour; your real rate is the one on the offer:
| Disk | Cost while stopped (illustrative) | Time from ¥0 to −¥35 (illustrative) | Destroyed after (illustrative) |
|---|---|---|---|
| 200 GB | ¥0.40/hour | about 87 hours, over 3 days | about 87 hours |
| 500 GB | ¥1.00/hour | 35 hours, about 1.5 days | 35 hours |
| 1,000 GB | ¥2.00/hour | 17.5 hours, under a day | 24 hours |
| 2,000 GB | ¥4.00/hour | under 9 hours | 24 hours |
Auto-destroy waits for whichever comes later: 24 hours at or below ¥0, or the balance reaching −¥35. At that illustrative rate the window is a day to a few days, not a month. A long weekend is enough to lose a large disk.
Size disks for the job. A 2,000 GB disk provisioned out of habit costs ten times as much to park as a 200 GB one; at the same illustrative rate it reaches −¥35 in under 9 hours — leaving only the 24-hour grace period between you and its deletion.
Watch the balance chip. The credit balance in the console header refreshes about once a minute and turns amber once it drops below ¥35. Treat that as the signal to top up, not as a warning you can sit on.
Keep a buffer before time off. If nobody will be watching the account, either destroy your instances or leave enough credit to cover their storage for the whole period, with room to spare.