kOlapsis/maintenant v1.7.0

Host OS end-of-support alerts

on GitHub

maintenant now tells you when a host's operating system is about to stop receiving security updates. A Debian 11 box that lost its free security support on 2026-08-31 no longer sits unnoticed: you get a warning a month before, then a critical alert once the date has passed.

Host OS end of support

Every monitored host reports its distribution and version: the server itself and every agent, whether it runs as a binary, in a Docker container or on a Kubernetes node. maintenant checks it against the support cycles of Debian, Ubuntu, RHEL, Rocky Linux, AlmaLinux, Alpine and SLES, and raises one host / os_eol alert per host:

• warning once 30 days or fewer remain before the end of free security support;
• critical the day after that date, escalated in place, not a second alert;
• resolved on its own when the host reports a newer, still supported version.

The date that counts is the end of free security support (for Debian, the end of LTS). Paid extensions such as Debian ELTS, Ubuntu Pro/ESM, RHEL ELS and SLES LTSS are shown for information but never used for alerting: maintenant cannot know whether you subscribe. The alert goes through the usual triggers and escalations; filter on the new host source.

Where the host OS comes from

The identity is always read at the source, never guessed:

• binary server or agent: /etc/os-release;
• in a container: the host's file, mounted read-only at /host/etc/os-release. Without the mount the host shows as unknown with the action to take, never the OS of the container image;
• on Kubernetes: the node's osImage, no mount needed.

Distributions without published dates (Fedora, Arch, NixOS, Flatcar, Talos, derivatives such as Raspbian or Mint) are shown as not tracked and never alert.

Where to see it

• Updates: a new Operating systems block, one compact line per OS version with its hosts, the active / security / paid extended phases and the time left, plus an OS at risk card.
• Dashboard: the same OS at risk card in the Updates block, linking straight to that section.
• Agents and Kubernetes nodes pages: distribution, status badge and dates for each host.
• API: GET /api/v1/updates/hosts, os_counts on /api/v1/updates/summary, an os object on each agent.
• MCP: get_updates now also returns the hosts and the support table in use.

Support dates, online or offline

The support table ships inside the binary and is refreshed at each release build. When the server has outbound network access it also refreshes the table daily from endoflife.date: seven requests, no data about your installation. A failed refresh keeps the current table. Set MAINTENANT_DISABLE_OS_EOL_REFRESH=1 (or --disableOsEolRefresh) to stay on the embedded table, for air-gapped deployments.

See Host OS End-of-Support.

Also fixed

A container that crash-looped and then ran stably kept its restart_loop alert open until its next crash. Containers with an open restart alert are now re-checked every minute, and the alert resolves once the container is back under the threshold.

Upgrading

Add the os-release mount wherever you already mount /proc, for the server and for every Docker agent, then recreate the container:

volumes:
  - /proc:/host/proc:ro
  - /etc/os-release:/host/etc/os-release:ro

docker run … -v /proc:/host/proc:ro -v /etc/os-release:/host/etc/os-release:ro …

The install commands generated on the Agents page already include it. Kubernetes needs nothing: the regenerated manifest only adds an optional MAINTENANT_NODE_NAME, and existing DaemonSets keep working as they are.

Upgrade the server before the agents. Agents older than 1.7.0 do not report their OS: their host shows as unknown, update the agent until they are upgraded.

One server migration, applied at startup: six columns on the agents table.

MCP: get_updates returns { "updates": [...], "hosts": [...], "eol_table": {...} } instead of a bare list of image updates. A client that read the list at the root must now read updates.