Lifecycle & suspension

Suspend, unsuspend, and terminate flows across every Impulse module. Read-only fences, grace periods, restores, and the purge at the end — all coordinated by ImpulseCore so the behaviour is uniform.

1. The lifecycle states

State	What it means
Active	Customer paid; service is fully usable. Default new-order state once provisioning succeeds.
Suspended (in grace)	WHMCS suspended the service (non-payment, manual admin action). The module fences it and the data is kept for the suspension grace window. How it fences depends on the module: some relax the suspension to read-only so the customer can still get their data out, others keep the service fully disabled. Unsuspending before the window ends restores the service. When the window ends, the data is purged.
Terminated (in grace)	WHMCS terminated the service. Termination itself deletes nothing: access is fenced and the data is kept for the termination grace window, so you can still restore it. When the window ends, the data is purged.
Purged	The module has deleted the service’s resources — data, accounts, and any server dedicated to it. Not recoverable from the addon.

2. How suspension works (per module)

Each module ships a lifecycle handler that ImpulseCore calls when WHMCS suspends, unsuspends or terminates a service. Core owns the schedule, the customer emails and the purge; the module’s handler applies the fence and does the final deletion.

ImpulseObjects

• Suspend: WHMCS’s suspend disables the customer’s access completely; the module then relaxes that to read-only — the customer can still list and download objects (GET/LIST) but can’t upload or delete (PUT/DELETE) during the grace window.
• Unsuspend: restores the customer’s normal access policy.
• Purge (after grace): deletes the service’s access keys, buckets and their data, policies and user.

ImpulseDB Postgres

• Suspend: WHMCS’s suspend blocks logins; the module then switches the database role to read-only (default_transaction_read_only) and ends existing sessions, so the customer can still SELECT to extract data while writes are refused.
• Unsuspend: restores normal access.
• Purge (after grace): drops the database and role, removes the service from the shared connection pooler, and for a dedicated database destroys its server and DNS records and deletes its backups.

Other modules keep the service fully disabled for the grace window rather than read-only — ImpulseAuth, ImpulsePlesk, ImpulseCpanel, ImpulseValkey and ImpulseSecrets keep WHMCS’s suspension in place, and ImpulseVPS powers the server off and keeps it intact. Each module’s guide describes its fence.

3. Grace periods

Default grace windows shipped with each module:

Transition	Default grace	What happens
Suspension → purge	7 days	A final warning email goes out about 2 days before the purge. Unsuspending in WHMCS before then restores the service.
Termination → purge	7 days	A final warning email goes out about 2 days before the purge. Restore service in ImpulseCore’s Lifecycle tab brings it back before then.

The customer gets an email when the grace window starts, the final warning, and a confirmation once the data has been deleted. The templates are yours to edit in ImpulseCore → Email Center.

The grace window is your “oh wait, customer paid” buffer. ImpulseCore → Operations → Lifecycle lists every service in grace, with its expiry, warning status and fence status, and gives you:

• Cancel grace (suspended services) — lifts the fence and ends the grace window. It doesn’t change the service’s status in WHMCS.
• Restore service (terminated services) — cancels the purge and restores access. It doesn’t touch WHMCS billing or status: reactivate the service in WHMCS separately. Unsuspending a terminated service in WHMCS does not restore it; Core refuses it and alerts you instead.
• Force purge — ends the grace window now; the hourly purge task deletes the data within the hour.

Deleting a service in WHMCS while it’s in grace purges its data immediately. A purged service stays listed in the Lifecycle tab for 30 days as the record of the deletion; the audit log keeps its service.purged entry for 90 days.

4. What happens when a step fails

Suspension never deletes the customer’s configuration — the fence is reversible, and unsuspension lifts it. If a module that relaxes to read-only can’t apply that fence (for example its server’s admin proxy is unreachable), WHMCS’s stricter full suspension stays in place: the customer loses read access for the grace window, but nothing is lost.

If a purge fails partway through (network blip, admin proxy error), the service stays in grace past its expiry and the hourly lifecycle_purge task tries again on its next run. Purges are idempotent: each retry carries on from what the module’s own records say is left. A module whose handler can’t be loaded (deactivated mid-grace) is left untouched and shown as unhandled for you to resolve.

5. Changing the defaults

The grace windows and the warning timing are set by each module. ImpulseObjects, ImpulseDB Postgres, ImpulseAuth, ImpulsePlesk, ImpulseCpanel, ImpulseValkey and ImpulseSecrets use the defaults above: 7 days of suspension grace, 7 days of termination grace, and a final warning 2 days before the purge. ImpulseSearch lets you change all three in its Settings tab, and ImpulseVPS lets you change the suspension grace in its Settings tab (at least 1 day).

The purge is destructive

Once the grace timer fires and the module’s lifecycle handler runs the purge, the data is gone — the addon doesn’t keep a “scheduled deletion” snapshot, and some modules delete the service’s backups as part of the purge (ImpulseDB Postgres does for a dedicated database). Recovery from a purged service is otherwise a “restore from your own offsite backup” exercise, so use the grace window: restore the service or get its data out before the window ends.