📚 Browse docs

Automation

Automation lets Asternodis tell the rest of your tooling that something is happening. A failover is rarely an isolated act: you probably also want to silence monitoring, post to a channel, open a ticket, or flip a load balancer.

Admin only.

Events

A hook fires on any of four points:

EventFires
Before failoverimmediately before a failover begins
After failoveronce the failover completes
Before DR testimmediately before a non-disruptive test starts
After DR testonce the test run ends: the isolated copy is up, or the run failed or was cancelled. Stopping the test afterwards fires no hook.

They fire for single-guest and recovery-plan runs alike, scheduled DR tests included. A planned move and a failback fire no hooks.

The pre_ events are the useful ones for suppression: silence the alerts before the guest stops answering, not after your phone has already gone off.

Adding a hook

Give it a URL and pick the events it should receive (one hook record is created per selected event). On failure decides what a delivery error means: Ignore logs it and lets the DR operation continue; Block stops the operation when a Before hook fails. Use it only for a hook whose success the operation genuinely depends on. An After hook fires once the operation has already run, so its failure is logged and audited whichever you choose. Asternodis POSTs to the hook’s URL when the event fires, identifying itself with an Asternodis-hook user-agent.

Use Test on any hook to deliver a sample event immediately. Do this when you add it: a webhook you’ve never fired is a webhook you don’t know works, and a failover is a bad time to discover the URL was wrong. The row keeps the outcome (the time it was tested and whether it was delivered, or “failed” with the reason on hover) across reloads, so you can see at a glance which hooks have ever been proven.

A note on security

Hook deliveries are not currently signed. The receiving endpoint cannot cryptographically verify that a request genuinely came from Asternodis, so:

  • prefer an endpoint that is not publicly reachable, or one that carries a secret in the URL path
  • don’t have the receiver take destructive action on an unauthenticated POST alone

Treat a hook as a notification, not an authenticated command.