Skip to content

Soft delete & trash

What you delete does not vanish from the database right away. It goes to the trash, disappears from all normal views and can be restored for 30 days. After that Vesana deletes it permanently.

What ends up in the trash

The trash has one tab per kind:

  • Tenants
  • Hosts
  • Checks (host services)
  • Users (the username becomes available again immediately on deletion; the trash entry carries the deletion date in its name)
  • Dashboards
  • Alert rules
  • Notification channels
  • Collectors
  • Monitoring scripts
  • Device profiles
  • Icons
  • Maps
  • Status pages, report schedules and wiki articles — only while the respective preview feature is enabled

Profile checks belong to their profile. Deleted hosts, collectors and checks no longer count against the licence quota — deleting frees up room immediately.

Cascade

When a host is deleted, all its checks go to the trash with it — as one deletion batch. When a tenant is deleted, all its objects (hosts, checks, alert rules, channels, collectors …) go with it. Restoring brings back the whole batch.

Dashboards belong to a user, not to a tenant — they are not part of the tenant cascade and stay when a tenant is deleted. A dashboard from the tenant-dashboard era that still sits in the trash without an owner gets one when restored: its creator if they can still see it today, otherwise whoever restores it. Restoring a tenant from that era brings its dashboards back with it.

Trash view

Admin → Logs & Support → Trash shows the deleted entries you are allowed to see:

  • Tabs per kind, with counts
  • Time of deletion and who deleted it
  • Time left until automatic deletion
  • Restore and Permanently Delete, Delete All at the top

Depending on your permissions the view is called "Own trash", "Tenant trash" or "System trash (all tenants)". Outside the admin area, /trash is your personal trash with what you deleted yourself; permanent deletion is only possible in the admin area.

Restore

Restoring is creating. The same limits apply as when creating something new:

  • Besides trash.restore you need the permission to create that kind (for a host, hosts.create) — in the object's tenant.
  • The licensed host count and the limits per tenant are checked — including the checks that hang off a restored tenant. If the budget is insufficient, the message names the free slots and nothing is left half-restored.
  • If an active host with the same name exists in the meantime, Vesana refuses the restore with a message.
  • A restored check starts at PENDING instead of its frozen old status.
  • A restored device never hangs off a collector that has since been deleted; its checks run again immediately via the Active checker.

Prerequisite: the parent object exists (or is restored with it). If a host was deleted together with its tenant, restore the tenant first — the host comes back with it.

Agents, collectors and keys

When deleting a host, collector or tenant, Vesana asks what happens to the software on the devices:

  • Keep installed (default) — the agent or collector goes dormant: no checks, no logs, no discovery.
  • Uninstall — it removes itself from the device on next contact. Devices with an active local approval refuse and go dormant instead.

Deleting also deactivates the host's agent token or the collector's or tenant's API keys.

On restore:

  • Keys and tokens that were deactivated by this deletion become valid again. A dormant agent or collector then resumes on its own within about 5 minutes.
  • Keys and tokens you had deliberately revoked before stay revoked. The message after the restore then says that a new agent token (Host → Set up agent) or new API keys are needed.
  • The restore dialog shows per device what will happen — comes back on its own, must be reinstalled ("Uninstall" was chosen), uninstall is cancelled, or has not reported since the deletion.

On permanent deletion, dormant agents and collectors stop for good; their files stay on the device. An agent whose token has been deleted is rejected from then on.

Permanent deletion

Before the 30 days are up, Permanently Delete removes an entry immediately, together with its measurements and logs. Delete All empties the whole visible trash (confirmed by typing PURGE). Both require trash.purge and a fresh identity confirmation.

"Delete All" leaves entries of preview areas that are currently disabled on the instance untouched. A permanently deleted tenant also takes its stored credentials, notes and open notifications with it.

Auto-purge

Once a day (first one hour after the API starts) Vesana permanently deletes every entry that has been in the trash for more than 30 days — including measurements and logs — and writes an audit entry.

Permissions

The trash has three visibility levels instead of just yes/no, plus two action permissions:

Permission Effect
trash.view_own see only entries you deleted yourself
trash.view_tenant see all deleted entries in the tenant; dashboards only your own or ones you deleted
trash.view_global see across tenants — only effective in an assignment scoped to "All tenants"
trash.restore restore entries
trash.purge delete permanently

Instance-wide objects without a tenant (users, device profiles, tenants themselves) can only be seen and deleted by someone with trash.view_global for all tenants — trash.view_tenant is not enough.

trash.purge only belongs in admin roles — protection against mistakes is the trash's main job. The built-in Admin role does not have it; by default only the super admin can delete permanently.

Audit

Deleting, restoring and permanent deletion are recorded in the audit log.

Special cases

Open alerts on deletion

When a check with an active CRITICAL is deleted:

  • Notifications stop immediately (the check is no longer evaluated)
  • Existing alerts stay in the history
  • After a restore, the status is re-evaluated with the next result

Wiki articles linked to a check

When a check with linked wiki articles is deleted, the link is kept; after a restore the links work again.

Next