Skip to content
Security hardening, live updates and lease fixes
Verlocx

Leases, schedules and alerts

Time-to-live for VMs, project-wide lease rules with staged actions, power schedules and alert rules.

Leases

  • A lease gives one VM an expiry date and an expiry action: power off, suspend, delete or notify only.
  • Owners are warned 7 days and 1 day before expiry through the notification bell.
  • lease.renew lets people extend a lease by 7, 14 or 30 days or to a custom date; lease.manage creates, edits and removes leases.
  • Renewing an expired lease undoes what expiry did where possible: a suspended VM is resumed and a powered-off VM is started. A deleted VM cannot come back.
  • Statuses: Active, Expiring soon (within 7 days), Expired, and Action executed with a summary of what happened.
  • Leases can also be created and managed through the REST API, for example by CI pipelines that spin up short-lived VMs.
Use suspend for lab VMs people might still need; Resume puts the session back exactly where it was. Keep delete for disposable machines.

Group lease rules

A group lease is a project-wide rule that applies a staged lifecycle to every VM that matches its conditions, for example “lab VMs: notify after 60 days, suspend after 75, delete after 80”.

  • Conditions: VMID range, name (starts with, ends with, contains, equals or regex), tag, owner, OS family, cluster, node, status, age in days, and whether the VM already has its own lease. Match all or any.
  • Stages fire a number of days after an anchor: when the rule first matched the VM, or the VM's creation date.
  • Each stage runs one action (notify, shut down, stop, suspend or delete), can notify the owner and can add a message.
  • The editor previews how many VMs match, using the same logic the scheduler uses.
  • Stages that are already overdue when a VM first matches are skipped unless you enable retroactive mode, so a new rule cannot wipe an old fleet on its first run.
Creating a rule needs lease.manage plus the permission of every action in its stages, for example vm.delete for a delete stage.

Power schedules

  • A schedule runs an action (start, shutdown, reboot, power off or suspend) on chosen weekdays at a time in a chosen timezone.
  • Schedules can be switched off without deleting them; each row shows its last run.
  • Managing schedules needs schedule.manage.

Alerts

  • Alert rules watch CPU %, memory %, disk %, VM down, agent offline (minutes) or backup failed, with a severity, a threshold, an optional sustained-for duration and a VM scope.
  • Rules are evaluated every minute. Matches notify the VM owners (on by default) and appear on the Alerts page.
  • The Alerts page has Fired alerts and Rules tabs. Acknowledge (alert.manage) marks an event handled without deleting history.
  • Disk alerts look at each volume, so one nearly full drive is caught even when the total looks fine.
  • Visibility follows VM scoping: with vm.view.all you see everything, otherwise alerts on your VMs and rules that touch them.

Mail notifications

When an organization admin configures outgoing mail (SMTP), lease-rule notifications are also sent by email. The in-portal notification is always raised first, so a missing or broken mail relay loses nothing.

Features on this page

  • VM leases
  • Group lease rules
  • Power schedules
  • Alert rules
  • Leases over the API
More in Virtual machinesAll topics

See Verlocx in action

A 30-minute walkthrough on your use case — deployments, workflows, governance.

Hypervisor

We use your details only to handle this request — privacy policy.

Type to search the docs, the user guide, all features, the product pages and the changelog.

↑ ↓ to move↵ to openesc to close