Lifecycle: your components' end of support
Last updated:
A deadline, not a vulnerability
A vulnerability is a known defect that a fix repairs. An end of support is a date: after it, the vendor publishes no more security fixes, so future vulnerabilities will stay unfixed. It is serious, but it can be planned: a major upgrade is not done within the hour.
StatHall tracks both on two separate scales. An end of support is never a critical alert: it does not count on the phone’s app icon badge and does not wake you up at night.
What gets dated
| Component | Where the version comes from |
|---|---|
| Distribution (Debian, Ubuntu, RHEL, Alpine…) | the StatHall agent |
| Packages from a third-party repository (PostgreSQL from PGDG, Node.js from NodeSource, PHP from sury, Docker…) | the agent inventory, with each package’s origin (agent 1.3.16 or later) |
Running Docker images (postgres:13, node:20, redis:7…) | the container snapshot taken by the agent |
| Language and framework of an image built on your machine (PHP, Node.js, Python, Go, Ruby; Laravel, Symfony, Drupal, CakePHP) | the container snapshot: the language version inherited from the base image, and the composer.lock in the container’s working directory (agent 1.3.19 or later) |
| Frameworks and libraries (Django, React, Angular, Spring…) | the SBOMs pushed by your CI |
| Store requirements (Google Play targetSdk, iOS SDK) | the app’s configuration, to fill in |
| StatHall agent | the version reported by the agent |
| Supabase project database | the Supabase connector |
Dates come from the public endoflife.date calendar, synced daily. The cockpit downloads the whole calendar: no information about your fleet is sent to it.
Why a distribution package is not dated
A package shipped by your distribution follows the distribution. Debian keeps
fixing its python3 until the end of Debian, even after python.org dropped that
version. Only a package from a third-party repository follows its vendor’s
calendar.
Extended support
When extended support is active (Ubuntu Pro ESM, Debian ELTS), the distribution’s deadline becomes the extended one. StatHall detects it from the origin of the installed packages, with nothing to configure.
Badge levels
| Level | When | Alert |
|---|---|---|
| Supported | deadline far off, or not announced yet | — |
| End announced | under 12 months (distribution, database) or 6 months (the rest) | — |
| Plan it | under 6 months (distribution, database) or 3 months | P2 |
| Imminent | under 3 months (distribution, database) or 1 month | P2 |
| Out of support | deadline passed less than 6 months ago | P1 |
| Long out of support | 6 to 18 months after | P1 |
| Abandoned | more than 18 months after | P1 |
| Not covered | unknown date | — |
A distribution or database migration is prepared earlier than a library upgrade, hence the wider thresholds before their deadline.
Not covered means StatHall cannot date the component: an image built on your machine with nothing telling what it contains, a product without a public calendar, an unreadable version, or store requirements not entered yet. It is never shown as up to date: a target with an uncovered component has its health score capped at 90, and the card says which one.
Where to see it
- Target list, overview, target header: the badge shows the most overdue component.
- A server’s Security tab: the “Lifecycle” section lists all its components, dated or not.
- Lifecycle screen: every deadline across the fleet, sorted by severity then date, filterable by level and origin.
- Inbox: a single “End of support” alert per target, naming the most overdue component and listing the others.
- Phone: the same badge on your targets, and the same Lifecycle screen.
Notifications
The alert opens as P2 when a deadline approaches and becomes P1 on the day a component goes out of support, which is when it notifies you. Moving between levels within the same severity sends nothing: the badge and the inbox are enough.
If you acknowledge or close the alert, it stays closed until the next level change: no daily reminder for work you already know about. Once the component is upgraded, the alert closes by itself.
Apps: store requirements
Google Play refuses an update whose targetSdk is too old. The App Store refuses a binary built with an outdated iOS SDK. Neither of their APIs returns these values: enter them in the app’s configuration, General tab (the “Support” card on its dashboard links there when they are missing). StatHall warns you before each store’s published deadline.