Somebody has to track the end-of-life dates.

Every audit asks the same question, and it is never the one you prepared for: which of your systems are running software that no longer receives security patches? You know the answer for the big three. You do not know it for the PostgreSQL minor version, the Java runtime inside a vendor appliance, or the .NET version in an internal tool that nobody owns.

The spreadsheet always loses

The EOL spreadsheet starts as a good idea. It ends up with a last-edited date from two years ago, half the rows missing, and one row that says “check with Mike” for a system Mike left in March.

The failure is structural rather than personal. End-of-life dates are external facts that change on somebody else’s schedule. A spreadsheet is an internal document that changes only when a human remembers it exists. You are hand-syncing a document against a source that updates without telling you.

What I use instead

For the lookup itself I use eol.wiki. It tracks lifecycle dates for a bit over five hundred products across seventeen categories, in English and Chinese, and it is free with no account.

Each product page gives you the release history, the end-of-life date and the current support status — that last one is the part that actually matters, because “EOL next year” and “EOL three weeks ago” are entirely different problems. There is a version checker for the question you get asked in a meeting, and an EOL calendar view, which is the one feature that changes behaviour: seeing four of your dependencies land in the same quarter turns a pile of unrelated upgrade tickets into a single planned piece of work.

The part I did not expect is that the whole dataset is also published as static JSON. https://eol.wiki/data/v1/products.json returns all 518 products in one request with permissive CORS, and there is a per-product variant alongside it. Nothing links to it and there is no schema page, but it means the lookup does not have to stay manual. I pull it into a script and join it against my inventory, which is the only version of this that survives contact with a busy quarter.

I reach for it rather than a search engine because lifecycle dates are exactly the kind of fact search results get wrong. Half the pages ranking for an EOL query are affiliate posts or a vendor blog from 2019, stating a date with total confidence and no source.

The honest trade-offs

The important one first, because the site says it itself: the core lifecycle data comes from the endoflife.date API. The published dataset makes the ratio concrete — of 518 products, 464 are re-published endoflife.date records and 54 are eol.wiki’s own curation. So if everything you care about is Node, Postgres and Ubuntu, you do not need this at all. endoflife.date is free, open source, and has a documented API you can call from a script.

• Judge it on the 54 products it curates itself, and on the tooling around the data, rather than on the catalogue size. That curated slice is also the data most likely to be thin or stale, precisely because it is maintained by hand instead of inherited.
• The inherited data has holes. Across 8,709 version cycles, 757 carry no end-of-life date and roughly five thousand have no active-support date. A missing date is not the same as support, and it is the answer most easily mistaken for good news.
• It is a reference, not an inventory. It has no idea what you are running. The join between “what the world says is end of life” and “what is deployed across my forty hosts” is still your job, whether that is a CMDB, an agent, or forty SSH sessions.
• Freshness depends on when someone last looked. The about page carried an updated date of 2026-08-21 when I checked, and only the curated products carry a verified date at all. Confirm anything you are about to make a decision on against the vendor’s own lifecycle page, which is the one source that cannot be wrong about itself.
• The project is anonymous. There is no named owner, and contact, privacy, terms and pricing all return 404, so there is no stated data licence either. Its llms.txt also advertises 450+ products where the pages say 518+. None of that breaks anything, and the site does run analytics, so it is not the reference to reach for if you want zero tracking — but it tells you how much process sits behind the numbers.

Where it fits in the loop

Two uses. The first is batch: once a quarter, take the handful of components you already plan to touch, check their dates, and put the end-of-life date directly in the upgrade ticket. The second is the two-in-the-morning one, where something has broken and you are deciding between patching it and rebuilding it. Knowing the support window usually settles that argument in about ten seconds.

The real fix is upstream of both, though. The time to record an end-of-life date is when you deploy the thing, not when you audit it. Anything that depends on somebody remembering to check quarterly gets checked for about two quarters.

It is bookkeeping and nobody gets promoted for it. But “we knew it was end of life and did nothing” and “we did not know” are different conversations, and only one of them ends well.