Skip to content

Acknowledgements

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

  • Marked as error (default, „is being fixed") — „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.
  • Marked as no error („not planned to be fixed") — 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
Error overview, host detail, check detail check row or context menu → Acknowledge
Downtimes & ACKs tab ACKs → New ACK → tenant → devices → pick open problems

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

  • Classification (see above) — default „Marked as error".
  • Optional „Limited until" — a due date. Once it passes, the ACK is lifted automatically (status goes back to „open", notifications/escalation resume normally). Above it sits the same quick pick as on downtimes (15 min up to 1 month, including „until end of day" and „until tomorrow 08:00" — the same list as on downtimes); one click sets the deadline and turns the expiry on at the same time.

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
  • Recovery, provided the alert was sent and the channel receives recoveries according to the per-channel fine-tuning

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 the error overview: select several checks → ACK All (N) with a shared comment (including classification and expiry). Writes one ACK per check with the same settings. Alternatively via New ACK on the Downtimes & ACKs page.

Revoke ACK

Check detail or the Downtimes & ACKs page → Remove ACK (for a bulk ACK: all of its still open checks at once). The status stays as it was, notifications resume, and escalation continues at the stage where it stood — stages that became due in the meantime follow one after another; it does not restart at stage 1.

ACK history

Every ACK is kept — who acknowledged, why, with which classification and expiry, how bad the check was at that moment, and how it ended:

End Meaning
check OK again the check recovered (auto-clear)
status got worse automatic break on worsening
expired the expiry was reached
removed someone removed it (their name is shown)
re-acknowledged it was replaced by a new ACK
check reset the check was reset (e.g. re-enabled)

Where you see it:

  • On the check (check panel and full view), section ACKs & downtimes — collapsed it already says „acknowledged 3×, last 2 days ago" and the last reason.
  • On the page Downtimes & ACKs, tab ACKs, below it the tabs Open and Completed with a count and their own paging. A bulk ACK across many checks is one row (expandable). Filters as on downtimes — plus classification (as error / as no error) and, in „Completed", the end (e.g. only „expired").
  • In the check's history graph as a band along the top, and in its event list.

Resume on an ended ACK opens the ACK dialog with the same reason, classification and the same expiry duration from now. It only works for checks that are not OK right now — an ACK on an OK check would be cleared by the next result.

ACKs from before this history existed were reconstructed from the audit log (marked as such); their end is derived.

Audit

In the audit log: acknowledge, bulk_acknowledge and unacknowledge, each with comment, classification and expiry.

Permission

Permission alerts.acknowledge (operator and above). Without it, the ACK buttons in the error overview and host detail are locked. Reading the history needs services.view, like every other check data.

Next