Activations

Last updated 2 November 2026

Read this when you need the exact rules behind waking and sleeping: what is checked before a Machine runs, what holds it awake, and how it stops and continues. The promise they keep is on Sleep guarantees.

An activation

Each wake of a Machine is one activation, with an id of its own, from its admission to its release; every activation boots fresh. At most one activation of a Machine runs at a time.

Admission

The edge checks the caller first. Then the controller takes the Machine’s lock, checks the region, the crash backoff and capacity, makes sure the Machine’s image is on the chosen host, asks Billing to place the first 10 minutes hold (see Metering and holds), mints the database token and starts the virtual machine. A step that cannot decide refuses, and nothing runs; each refusal is a problem document (see Troubleshooting).

The hold

The edge holds a waking request up to 25 seconds, then answers 503 with Retry-After by the reason: 1 s while it starts, 5 s while its image is pulled, 15 s while money is uncertain, and 30 s for capacity.

Activity and release

The edge reports each Machine’s open requests every 15 s, each report good for 45 s. The controller releases the activation sleep_after_seconds after the last one closed, or after 2 minutes with no open request when the Machine used at most 20 thousandths of one vCPU and 64 KiB a minute of network and had no open network connection of its own. The host reports the Machine’s own open connections, so a connection it opened keeps it from the early release even while it carries no traffic, but never past sleep_after_seconds.

Crash backoff

After 3 failed wakes within 5 minutes, the controller refuses wakes for 5 minutes, with the rest of the backoff as Retry-After.

Stops and the drain

An activation ends for one reason, recorded by its code: sleep_after, idle_early, sleep_requested, machine_deleted, account_deleted, funding_stop, platform_release, workload_exited, oom or metering_unavailable. A planned stop that releases the Machine sends SIGTERM, waits the grace (at most 60 s in a funding stop), then drains: the host sends what the database still had to send, within 60 s and inside the time already paid for (see Database wiring). A crash or the loss of the host skips the drain.

Release, not suspend

• An idle sleep, a sleep you request and a host removal all release the Machine: the program gets SIGTERM, the host drains the database, and the virtual machine ends. Tonbo does not suspend Machines, and keeps no snapshot (status.snapshot is always null).
• The next wake boots the image fresh, with the database intact and the Volume, if any, mounted again at its path.
• status.sleep gives the action, release, with the reason requested when you set idle_action to release, and otherwise suspend_unavailable.

The other reasons machine-v2 names for a release, which a Machine does not give now:

• shape_above_cap
• insolvent
• spec_changed
• databases_unknown
• volume_pairing_unavailable