Skip to content

Downtimes

A downtime is a window during which a host or service is expected to fail — maintenance, reboot, migration. Alerts aren't sent during an active downtime.

The „Downtimes & ACKs" page

Downtimes and acknowledgements share one page (menu Downtimes & ACKs, two tabs). Inside the Downtimes tab you pick the state below, again as tabs with a count: Running, Scheduled and Completed. Each shows its own list with its own paging.

One row = one operation: a window across 40 devices is one row („pve01, nas02 +38"); a click expands the individual devices and checks.

Filters (apply to both tabs and live in the address — a link opens exactly this view):

  • Search in reason, device, check and tenant
  • Tenants, devices and created by — each a multi-select; the device list only offers devices that occur in the history, with a count, and searches on the server as you type (even with thousands of devices)
  • Time range — any time, last 24 hours, 7 or 30 days, or Custom (from–to); shows what falls into that range
  • End (only in the „Completed" tab, multi-select) — e.g. only windows ended early

Every active filter appears as a chip below the bar and can be removed on its own. From a check („All … of this check") the page opens already filtered to this device and this check; removing the check chip shows everything for the device.

Every row shows target, time range and duration, the reason, who created it — and under „Completed", when and how it ended and by whom:

End Meaning
expired the planned end was reached
ended early someone pressed End (their name is shown)
edited (replaced) the window was changed in the dialog on a check and replaced by a new one
disabled a recurring downtime with an invalid recurrence was switched off
  • Edit (running/scheduled): change the reason, extend it or end it sooner — applies to the whole operation. The start of a running window stays; for recurring downtimes only the reason can be changed.
  • End or Cancel (scheduled): the window ends immediately.
  • Resume (completed): opens the create dialog with the same settings — target, scope, reason, recurrence and the planned duration from now. Time and reason can be changed before saving.

On the check itself (check panel and full view), the section ACKs & downtimes shows this check's history — including downtimes that covered it via its device or the whole tenant. In the check's history graph, maintenance windows appear as a hatched area and ACK periods as a band along the top.

Concept

[Live status]                    Service: CRITICAL
[during active downtime]         Status visible, no alert
[after downtime]                 If still CRIT → alert (or recovery)

Create a downtime

Downtimes & ACKs → Create Downtime — or on the device under History → Downtimes & ACKs (the device is preselected there). For individual checks you can also start right from the error overview and the check detail ("Schedule Downtime", with a bulk downtime for several selected checks).

Field Meaning
Tenant Required; it also filters the device list below. With only one tenant it is preselected
Target Entire tenant or Select devices (one or more)
Scope Whole devices (all checks) or Specific checks of the selected devices
Start Date + time, required
End Date + time or a preset (see below)
Comment optional — what's happening, by whom
Repeat optional: None · Daily · Weekly · Monthly, see Recurring downtimes

Date and time are in the instance time zone (Admin → Notifications → E-mail & Messages); if none is set, in the browser's time zone.

Entire tenant

For the cases where everything really is down — a power cut, a site move, maintenance of the whole environment — pick Entire tenant as the target. That is one maintenance window, not one per device: you end it with a single click, and it also covers devices that are created while the window is open.

How to spot it in the list

Such windows show the tenant name plus „all devices" as their target instead of a device name.

Multiple devices

Under Select devices you tick any number of devices of the tenant. That becomes one maintenance window: it shows as one card with all device names and ends for all of them with a single click on End. Either each device is fully covered (all checks), or you switch the scope to Individual checks: the list then shows the checks of all selected devices, grouped by device. Above it are the checks that exist on every selected device (same name) — one click picks e.g. the backup check on all servers. That, too, stays one maintenance window.

Presets

Instead of setting start/end manually, presets are available: 15 min / 30 min / 1 hr / 2 hrs / 4 hrs / 8 hrs / 12 hrs / 24 hrs / until end of day / until tomorrow 08:00 / 2 days / 3 days / 1 week / 2 weeks / 1 month. One click sets start = now and computes the end automatically; the chosen preset stays highlighted until you change start or end by hand; you can still fine-tune the window afterwards. The same list appears in the downtime dialog on a device and under „Limited until" when acknowledging.

Recurring downtimes

For regular maintenance windows choose under Repeat:

Option Effect
Daily every day at the time from start to end
Weekly on the selected weekdays (without a selection: on the weekday of the start)
Monthly on the calendar day of the start (a window on the 29th–31st does not slip to the 28th; months without that day are skipped)
Ends Never or On a date — the end applies until the end of the chosen day

Start and end define the first window and thus the duration of every occurrence. Below the selection a summary is shown, e.g. "Weekly (Mo, We) 02:00–04:00 (Europe/Rome)".

Weekday, day of month and time are evaluated in the instance time zone — "every Monday 00:30" stays Monday 00:30 local time, across daylight-saving changes too. Without an instance time zone, UTC applies. (Up to v1.903.0 the calculation was always in UTC.)

Rejected when saving: a repeat end before the first window, rules that never match (e.g. on 30 February), and rules that are too dense (every second; for hourly or minutely repetition via the API only time parts, no days). Existing rules that are no longer allowed are switched off once by Vesana; they then show up in the history as "disabled" and in the diagnostic log.

A running recurring downtime can only be edited in its reason — for other times, end it and create a new one.

Downtime lifecycle

stateDiagram-v2
    [*] --> Scheduled: created, start in future
    Scheduled --> Running: start reached
    Running --> Expired: end reached
    Running --> Ended: „End"
    Scheduled --> Ended: „Cancel"
    Running --> Replaced: edited on a check
    Expired --> [*]
    Ended --> [*]
    Replaced --> [*]

A background job ends expired windows and switches maintenance off on the checks. Ended downtimes are kept as history.

Effects

During active downtime:

  • Check runs as normal
  • Status visible in UI with maintenance badge
  • Alert rules ignore the service
  • Mobile push: not sent
  • Email notifications: not sent
  • Webhooks: not sent

The suppression applies live — the alert path itself checks for an active downtime, rather than relying on a separate background job that only catches up on the maintenance flag a few seconds later. So there's no brief window right after a downtime starts where an email could still slip out.

In the audit log: starting and ending a downtime is recorded with author and comment.

SLA accounting

SLA calculations take maintenance windows out of the calculation to the minute — the time counts neither as available nor as outage. This applies equally to downtimes on individual checks, devices and whole tenants.

Details: SLA reports.

Multiple devices via API

Same as in the dialog: host_ids instead of host_id creates one maintenance window for all listed devices (all devices must belong to the same tenant).

curl -X POST -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{
    "host_ids": ["<uuid-1>", "<uuid-2>"],
    "start_at": "2026-04-25T22:00:00Z",
    "end_at":   "2026-04-25T22:30:00Z",
    "comment":  "Reboot after kernel update"
  }' \
  https://your-domain.tld/api/v1/downtimes/

The response carries batch_id; DELETE /api/v1/downtimes/batch/<batch_id> ends the window for all devices at once.

End early

Running downtime → End. Alerts fire again right away; the history shows „ended early" with time and name.

Useful when maintenance finishes early — you want to know if anything's still broken.

Audit

In the audit log: downtime_create (or bulk_downtime_create), downtime_update (with before/after) and downtime_delete (with reason ended or replaced).

Next