---
title: "Lifecycle: your components' end of support"
description: "The Support badge tells where each component stands with its security fixes — distribution, databases, images, dependencies, store requirements — on a scale separate from vulnerabilities."
lang: en
canonical: "https://www.stathall.com/en/docs/cycle-de-vie/"
updated: "2026-09-30"
---

# Lifecycle: your components' end of support


## 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](https://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.