Skip to content

Acknowledgements

An acknowledgement (ACK) first of all means: „I've seen this." What happens next depends on a checkbox in the dialog — „Is a problem":

  • Checked (default) — „in progress": the check stays a real problem and keeps counting in all rollups (health bars, problem counters, the bell). Only further notifications stop going out while you're on it.
  • Unchecked — accepted exception: the check stays visible in its non-OK state (its own „accepted" color), but stops counting in any problem rollup. Useful for known, deliberately tolerated states — e.g. a test device that permanently reports an off value and shouldn't bother anyone anymore.

Compared to downtime: ACK isn't an expectation set in advance („this is maintenance"), but a reaction to an ongoing problem.

Setting an ACK

Where How
Web UI Host detail / error overview → service row → Ack
Mobile app Host detail → service → Ack button

Required field: Comment — what's happening, who's on it. Also in the same dialog:

  • Checkbox „Is a problem" (see above) — checked by default.
  • Optional „Expires at" — a due date. Once it passes, the ACK is lifted automatically (status goes back to „open", notifications/escalation resume normally).

Notifications (email, Slack, Teams, …) link directly to the affected check — you acknowledge from the Vesana UI they point to; there's no separate Ack button inside the message itself.

Effect

  • Further notifications of this alert rule are suppressed
  • Escalation pauses
  • Status visible in UI with ACK badge + author + comment
  • SLA: ACK does not count as downtime — the service is still counted as in outage (exception: deliberately accepted checks drop out of the problem rollup, see above)

Automatic break on worsening

If an acknowledged or accepted check gets worse than it was at the time of the ACK (e.g. acknowledged at WARNING, then turns CRITICAL), the ACK breaks automatically: the check becomes a real, unacknowledged problem again and notifications resume. So acknowledging at WARNING level doesn't shield you from being surprised by an actual escalation.

Auto-clear on recovery

When the service is OK again:

  • ACK is cleared automatically
  • Status to OK
  • Optional recovery notification (configurable per channel)

If the service then jumps back to CRIT (a new problem, or flapping), the ACK is already gone by then — the new problem runs through as a completely fresh alert, with its own wait time and escalation starting at stage 1.

ACK + downtime

Both can apply at once. ACK is operator action, downtime is planned maintenance. A service can be acknowledged while a downtime is laid over.

ACK in bulk

In error overview: select multiple services → Ack all with a shared comment (including „is a problem" and expiry). Writes one ACK per service with the same settings.

Revoke ACK

Service detail → Remove ack. Status stays as critical as it was, notifications resume, escalation restarts (stage 1).

Audit

ACKs are logged with track_change — author, service, comment, time. Filter in audit log: action = ack.create / ack.clear.

Permission

Permission service.ack (default for operator+). Without it, the Ack button is disabled.

Next