End of life

A version the vendor no longer fixes will never get a CVE to warn you: its end of life is its due date. TechWatchAlert keeps a catalogue of end-of-support and end-of-life calendars for common products (source: endoflife.date) and helps you follow those in the project’s stack.

Two screens handle it:

• Monitoring › End of Life: the catalogue, the versions in the project’s stack, and the subscriptions that warn you before a deadline or when a new version ships;
• NIS2 compliance › Due dates, End of life view: for NIS2 projects, the stack versions that are out of support or about to be, and their exit plan.

The End of Life page

Open it from Monitoring › End of Life. The active project’s name is shown next to the End of Life (EOL) title.

At the top, the filter bar, the same as on the CVE and Alerts pages (see Searching and filtering):

1. product search, the scope (My stack, Followed, Whole catalogue), Quick views and the sort;
2. the statuses, with the number of versions in each, then LTS, Security only and the deadline;
3. the number of products and versions found, chips for the active filters and Clear all.

Below, the product table: a click on a product row expands or collapses it, the STACK badge marks a product in the project’s stack, and the bell in the Follow column subscribes the project.

Products and versions

The table is grouped by product; pagination counts products (Rows per page: 25 or 50, bottom right).

On a product row:

Column	Content
Product	Name, catalogue identifier (postgresql, django…), STACK badge.
Version / Cycle	Number of versions of the product.
Latest version	Latest release of the newest branch, with that branch’s name underneath.
Release date, End of support	Those of the newest branch.
End of life (EOL)	The soonest end of life among the product’s versions: red if past, amber if within 180 days.
Status	Summary: Active Support if at least one version is supported, otherwise Ending Soon if one is close to its end, otherwise End of life if all have passed, otherwise No date. Hover: the breakdown by status.
Follow	The Track new versions bell.

On an expanded version row: the cycle’s latest release, the cycle (an LTS badge for long-term support), its dates, the end of life with “in N d” (within the coming year) or “N d ago”, the version’s status and the Track (end-of-life / support) bell. Versions are listed from newest to oldest.

A version’s status:

Status	Rule
End of life	The end of life has passed, or the vendor declared it without a date.
Ending Soon	The end of life falls within 180 days.
Active Support	The end of life is further away.
No date	The catalogue has no end-of-life date.

Searching and filtering

Searching

The Search a product field filters on the catalogue name or identifier (“postgres” finds PostgreSQL). The list follows your typing after a short pause; Enter applies the search at once, Esc clears the field, and the / key puts the cursor in it from anywhere on the page. A product the search names exactly (“postgresql”, “PHP”) expands by itself.

Filtering

Filters apply at once and add up; any filter change goes back to the first page.

• Scope, right of the search: Whole catalogue (default) shows every known product; My stack keeps only the products in the active project’s stack; Followed, those the project has at least one subscription for (product or version). For My stack, matching is on the exact name: the stack item must carry the catalogue identifier (postgresql, nginx, php…). Without an active project, the scope is hidden and the page shows the whole catalogue.
• Status: End of life, Ending Soon, Active Support, No date, combinable. Each shows its number of versions, counted with the search, the scope and the other filters, but without the status filter: you read what a click would give.
• LTS: the vendor’s long-term support versions.
• Security only: active support is over but end of life has not been reached; the vendor only ships security fixes. Time to plan the upgrade.
• Deadline: Any deadline (default), or an end of life falling within 30 days, 90 days, 12 months or 2 years, from today. Versions already past their end of life are not included: the End of life status shows them.

Hover LTS or Security only for details. This page has no “Advanced filters” panel: all its filters are in the bar.

Quick views

Quick views, right of the scope, sets a common combination in one click:

• My stack, out of support: My stack, End of life status;
• My stack, ending soon: My stack, Ending Soon status;
• Followed: end of life within 90 days: Followed, 90-day deadline;
• Security only;
• Supported LTS versions: LTS, Active Support status.

The first three need an active project. A view replaces the search and the filters set; the sort and the rows per page stay. When the filters match a view exactly, the button shows its name.

Active filters

Below the bar, a line gives the number of products and versions found (“8 products · 16 versions”), then one chip per filter set: “Scope: My stack”, “End of life”, “LTS”, “End of life within 90 days”… A chip’s cross removes its filter. Clear all removes the search and every filter, scope included, keeping the sort and the rows per page.

Sorting

The sort, right of the quick views: Product (alphabetical, default) or Deadline, which orders products by the soonest end of life among their matching versions, oldest first; products without a date come last.

Sharing a filtered list

The search, filters, sort, page and rows per page are written into the page address, without a history entry for each click: a copied link reopens exactly the same list. Only departures from the defaults appear.

Parameter	Meaning
q	search (product is read the same way)
scope	scope: stack or followed (absent: whole catalogue)
status=eol,ending_soon	statuses (eol, ending_soon, active, unknown)
lts=1, securite=1	LTS, security only
echeance	deadline: 30j (30 days), 90j, 1a (12 months) or 2a (2 years)
sort=eol	sort by deadline (absent: Product)
page, page_size	page, rows per page (25 or 50)

Links in the app use it: the dashboard’s EOL < 30 days counter opens the page on Followed, 30-day deadline; a row of the deadlines widget, of an end-of-life email or of a Vigie product card opens that product, expanded. A link from an email also activates the notice’s project.

On a phone

The search takes the full width; below it, a toolbar stays visible while scrolling: Filters (with the number of filters set), Sort and the range shown (“1–25 of 44”). Active-filter chips scroll in one row, followed by Clear all. Filters opens a sheet with the quick views, the scope, the statuses, LTS, Security only and the deadline; filters apply at once, and the bottom button announces the number of products found.

Subscribing: versions and new releases

Two subscriptions, two purposes:

A version

The bell on a version row: “warn me before the end of support and before the end of life of PostgreSQL 15”. Follow every version you run.

The product

The bell on a product row: “warn me when a new Django version ships”. Useful to prepare upgrades.

Clicking the bell subscribes the project; the bell turns solid and framed. A second click unsubscribes. A version already past its end of life can still be followed: its end of support may still be ahead. With no active project, bells are disabled (“Select a project to enable EOL subscriptions”).

Subscriptions belong to the project: all its members see them. They can also be created when adding a product to the stack, through the Track end of life? window (see Stack).

When are you warned?

A check runs every hour:

• version subscription: before the end of life, then before the end of active support, once each. The lead time is the subscription’s if it sets one, otherwise the project’s (project settings, General tab, Team notifications card: Warn before end of support and Warn before end of life, from 1 to 365 days, shared by the whole team and editable with the “Edit EOL subscription” right), otherwise 60 days. If the end date changes in the catalogue, or the lead time changes, the notice goes out again for the new deadline;
• product subscription: as soon as a version that was not in the catalogue when you subscribed appears.

Notifications go through the project’s workflows, created with it: Default end-of-life workflow (end of life approaching), Active support ending and New releases, which send an in-app notification to each project member. A disabled workflow warns nobody; see Workflows.

Subscribe early

The notice goes out when the deadline is within the lead time (60 days or less by default). A subscription created after the date has already passed therefore triggers a notice at the next check, once. As long as no active workflow handles the event, nothing is marked as sent: the notice goes out as soon as a workflow listens to it.

End of life in the NIS2 area: the Due dates view

For projects where NIS2 is turned on, NIS2 compliance › Due dates, End of life view, treats unsupported versions as remediation deadlines: a state, a delay, an escalation, an owner. The number on the End of life tab counts unsupported components (overdue and escalated).

1. Vulnerabilities / End of life: the two views of the Due dates page (the first is covered in NIS2 registers).
2. Indicators by state; a click filters the list on that state, a second click removes the filter. Under End of life within 180 d, the number of components without an exit plan.
3. Project: all projects, or one.
4. How is the due date calculated?
5. End-of-life catalogue: opens the End of Life page.
6. A component: product, cycle, versions in service, project, latest release of the cycle.
7. Plan: opens the exit plan.

Which components?

A component is a product-cycle pair in a project, worked out on every display:

• from the project’s stacks (all its members’): a product item whose name is a catalogue identifier, matched to its cycle through its version (“1.1.1t” belongs to cycle “1.1.1”, “8.9p1” to “8.9”, but “3.12” does not belong to “3.1”);
• from the project’s version subscriptions.

A stack item with no version, or whose version matches no cycle, cannot be assessed: it is counted, and a banner says so (“… have no usable version”) with a Complete the stack link. A version with no known end-of-life date does not appear.

States

State	Rule
Supported	End of life more than 180 days away.
End of life soon	End of life within 180 days: time to plan.
Exit planned	End of life passed, but a dated exit plan in the future covers the component.
Unsupported	End of life passed (or the exit plan itself is overdue).
Escalated	Unsupported for longer than the escalation delay of the project’s remediation policy.

The Left column gives the gap in days: D-47 means 47 days before the end of life, D+19 19 days overdue. The list is sorted by state (escalated first), then by gap, then by criticality. Criticality is the highest among the stack items concerned, otherwise the project’s.

Planning the exit

A click on a row (or on Plan) opens the component’s panel:

• Vendor calendar: end of life, end of active support, latest release of the cycle and source (Vendor notice when a link exists, otherwise endoflife.date);
• Exit plan: when the version will be replaced, by whom and how.

1. Choose the Planned exit on date (today at the earliest), or a 1 month, 3 months or 6 months shortcut. The text below gives how many days away it is and what the date implies: replacement before the end of life, an unsupported period covered by the plan, or the delay suspended for a component already unsupported.
2. Choose the Owner, a project member, notified if the date is missed.
3. Add a Note (2,000 characters max), for instance the target version and planned tests.
4. Click Save the plan.

Clear the plan removes the date, the owner and the note. The panel shows who last changed the plan, and when.

A plan dated after the end of life pushes the deadline back to its date: the component moves to Exit planned and no longer counts as overdue. Once that date passes, it is Unsupported again and escalation resumes. A plan dated before the end of life does not bring the deadline forward. Every plan is logged and appears in the management report.

Automatic notices

• A component that becomes unsupported is announced to its plan’s owner if they are a project member, otherwise to the project’s administrators and owner.
• An escalated component is announced to the security lead (CISO role).
• Notices are grouped by project and sent once per step; an exit plan that slips re-arms the step. There is no “end of life soon” notice here: the End of Life page subscriptions take care of that.

In the NIS2 posture

The NIS2 compliance overview has an End of life block (“Versions the vendor no longer fixes are replaced under a dated plan.”): overdue when there are unsupported or escalated components, to do when there are close ends of life without a plan, otherwise compliant. Its actions lead to the matching filters of this view, and to the stack for versions to fill in. Unsupported or close components appear in the annex of the management report.

Who can do what

Action	User	Analyst	Admin	Owner
View the End of Life page	✓	✓	✓	✓
Subscribe (bell)		✓	✓	✓
Unsubscribe		✓	✓	✓
Set the project’s warning lead times (Team notifications card)		✓	✓	✓

These are the default rights; they can be set member by member or per group (“Subscribe to EOL”, “Unsubscribe from EOL” and “Edit EOL subscription” rights), and the server applies the result.

In the Due dates End of life view, reading follows access to the NIS2 area, and planning an exit needs the Record an inventory review right (granted by default to the project’s Analysts, Admins and Owner).

Each row knows whether you can plan: without the right, the panel shows the plan read-only, or “No exit plan. It is planned by a project member allowed to record inventory reviews.”. Organisation owners and administrators, and holders of a NIS2 role, see every NIS2 project in the organisation.

What depends on your plan

• The End of Life page must be included in the plan; otherwise its menu entry is locked.
• The number of subscriptions is capped for the whole organisation. With the instance’s default settings: 5 on Free, 50 on Team, unlimited on Pro and Business. Beyond that, the plan picker opens.
• The Due dates End of life view needs the NIS2 compliance area and its Due dates module (Pro and Business plans), and a project where NIS2 is turned on.

FAQ

My product is in the stack, but “My stack” does not show it. Matching is on the catalogue’s exact identifier. An item named differently (say node.js instead of nodejs) is not recognised. Subscribe to the version from Whole catalogue instead: the subscription also counts in the Due dates view.

Why doesn’t my version show in Due dates? You need a version in the stack (or a subscription to the version), a cycle matching the catalogue, a known end-of-life date, and NIS2 turned on for the project.

StackSet exact versions.

NIS2 registersRemediation due dates, inventory reviews.

WorkflowsEnd-of-life notifications.

GET …/eol (API)Read subscriptions through the API.