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, and the GPUs of stopped instances are released where the machine supports it	kept, and still billed
has been at or below $0 for 24 hours and is at or below −$5	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. Nothing is destroyed while a payment dispute on the organization is open.

Auto-destroy deletes the disk

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 −$5.

At $0: auto-stop

When the settlement pass finds an organization at zero or below:

• Every instance in the running state is stopped. The container shuts down and the disk is kept, but unlike your own stop, this one releases the GPUs back to the machine, where the machine supports it: nobody is paying for them, so other renters may use them.
• Instances that were already stopped — including ones you stopped yourself, whose GPUs were reserved for you — have their GPUs released the same way.
• GPU charges end. Storage charges continue, at disk size multiplied by the storage rate per GB-hour.
• A released instance keeps its container and its disk on the machine, and it can be started again after a top-up — but only on the same GPUs. If another renter is using any of them by then, the start is refused with 409 CAPACITY_UNAVAILABLE and the instance stays stopped with its disk. See Stop vs destroy.
• Where a machine cannot release GPUs, or the instance runs a vm template, they stay reserved for the instance, as after your own stop, and it still bills storage only.
• Deploying a new instance and starting a stopped one both fail with INSUFFICIENT_BALANCE until 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 for a running instance and instance.auto_released for a stopped one; the console's usage page shows them as Auto-stopped (balance) and GPUs auto-released.
• 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, and nothing re-reserves released GPUs either: the next Start re-claims them, if they are still free.

While a payment dispute is open

A formal payment dispute freezes the organization's payments, and starting a stopped instance is refused with 402 PAYMENTS_FROZEN until it closes. Holding GPUs for instances that cannot start would buy nothing, so while payments are frozen:

• stopped instances have their GPUs released at the next settlement pass, even when the balance is positive, where the machine supports it;
• a Stop you press releases the GPUs at once, where the machine supports it — the stop dialog in the console says so before you confirm — and the API's stop_releases_gpus reads true on every instance of the organization;
• the freeze on its own stops no running instance: they keep running and billing, and the zero-balance rule above still applies to them;
• nothing is auto-destroyed while the dispute is open.

Once the dispute closes, those instances are ordinary released stops: a Start works if the same GPUs are free. See Transactions and spend for what freezes and unfreezes an organization.

After 24 hours, at −$5: auto-destroy

Auto-destroy runs only when all three of these hold:

• the balance is at or below −$5;
• it has stayed at or below $0 for at least 24 hours without a break;
• no payment dispute is open on the organization.

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 payment confirms. 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 zero does not reset the clock. It only keeps the balance above −$5 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 to get an hourly figure, then work out how long your balance covers. With storage at $0.0002 per GB-hour:

Disk	Cost while stopped	Time from $0 to −$5	Destroyed after
200 GB	$0.04/hour	about 5 days	about 5 days
500 GB	$0.10/hour	about 2 days	about 2 days
1,000 GB	$0.20/hour	about 1 day	about 1 day
2,000 GB	$0.40/hour	about 12 hours	24 hours

Auto-destroy waits for whichever comes later: 24 hours at or below zero, or the balance reaching −$5. The window is a day or a few, 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, and reaches −$5 in half a day — 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 changes color once it drops below $5. 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.

Related

• How billing works
• Adding credits
• Stop vs destroy
• Start, stop and destroy
• Instance states