Skip to main content
The behaviour when your credit balance gets low depends on whether auto-recharge is enabled. The two paths share the same terminal step but reach it differently.

​
Path A: Auto-recharge ON

Recommended. Adds a “suspension” grace window before any destruction.
1

Auto-recharge attempts a top-up

Balance drops below your configured threshold → Suji charges your card for the configured top-up amount. On success, balance refilled and life continues.
2

Card declines → VMs suspended

If the recharge attempt fails (card declined, expired, monthly cap, etc.), running VMs are powered off and flagged as suspended.Important: suspension does not stop billing. The cloud provider still charges Suji for the powered-off server (the disk and IP stay reserved), and billing continues against your remaining credit. Your balance keeps decreasing.The user gets time equal to (remaining balance ÷ hourly rate) to fix the card.
3

Fix card → click Resume

Update your payment method, then click Resume. The VM powers back on in ~60 seconds. Same disk, same IP, same subdomain, no data loss.
4

Credit hits €0 → terminate + retain snapshot

If you don’t fix the card and credit reaches €0, the terminate flow runs (same as Path B below).

​
Path B: Auto-recharge OFF

No grace window. Balance hits €0 and the terminate flow runs immediately.
1

Balance approaches zero

Suji sends low-balance warning emails. The Billing page in the dashboard shows a persistent banner reminding you that auto-recharge is off.
2

Balance hits €0 → terminate + retain snapshot

The next metering pass after balance ≤ €0 runs terminate for every active VM in the org:
  1. Stop the VM gracefully.
  2. Take a cold snapshot of the disk.
  3. Mark the snapshot type='termination', retention 7 days.
  4. Delete the cloud server (provider billing stops here).
  5. The instance row is marked deprovisioning; Suji tears down the tunnel + DNS.
Suji emails you when this happens, with the recovery window and how to restore. Your data lives in the termination snapshot for the retention window.
3

Within 7 days → top up + restore

Top up to a positive balance, then go to Snapshots in the dashboard and restore the termination snapshot into a new VM. The new VM gets a new IP but the data is intact.Note: snapshot storage continues to bill against your credit during retention. With no VM running, the burn rate is tiny (a few cents/GB/month). It can push your balance slightly negative. That’s expected, the top-up clears it.
4

After 7 days → snapshot deleted

Expired snapshots are cleaned up automatically (checked hourly). Once that’s done, the snapshot is gone and your balance stops being debited for it.

​
Side-by-side

​
Recommendation

Enable auto-recharge. It gives you the suspension grace window between “card failed” and “balance gone”, which is usually plenty of time to fix the card. Without it, a single missed top-up means immediate VM destruction (recoverable via snapshot for a week, but more work). You set this up in Billing → Payment methods → Auto-recharge. Pick a threshold (when to top up) and an amount (how much to add).

​
Notifications

We email you as your balance runs low, when you have only a few hours of runway left, or you’ve dropped below your auto-recharge threshold, and when a VM is suspended or an auto-recharge attempt fails. Add additional notification recipients in Organization → Notification preferences.

​
What about volumes and other billable resources?

Every stored resource gets the same 7-day retention treatment at €0: volumes (attached or detached) are detached and kept intact, and manual/migration snapshots are marked for deletion. Everything in retention is still billed at the storage rate. Top up within the window and the retention marks are lifted automatically: your snapshots and volumes are kept. After 7 days without a top-up, they’re deleted and billing stops. Per-resource lifecycle rules at €0: