About GetEndOfLife

GetEndOfLife tracks the release and end-of-life lifecycle of 453 software dependencies, and alerts you when a version you rely on is deprecated or stops receiving security patches.

Why it exists

End-of-life dates are public information, which is exactly what makes missing one frustrating. Every project publishes its support policy somewhere, in its own format, on its own page, with no way to be told when something changes. So the dates sit there, correct and ignored, until the day someone needs a security patch that is never going to arrive.

The problem is not that the data is hard to find. It is that nothing tells you to go look. GetEndOfLife exists to close that gap: subscribe once to the dependencies you actually run, and the lifecycle events come to you.

Where the data comes from

Lifecycle data is sourced from endoflife.date, an open-source, MIT-licensed, community-maintained dataset. It is excellent work by a lot of contributors, and this site would not exist without it. GetEndOfLife does not originate end-of-life dates and does not override them.

What GetEndOfLife adds is a layer on top: daily polling, change detection, and delivery. If you only need to look a date up once, endoflife.date will serve you well and you should use it directly.

How current it is

Refreshed daily
The full catalog is polled every day, so tracked dates reflect the upstream dataset as of the most recent refresh.
Changes are detected
When a project announces an end-of-life date, or moves one it already announced, that difference is recorded as an event and sent to subscribers.
453 dependencies
Databases, language runtimes, operating systems, orchestration platforms, and infrastructure servers.
Verify before you act
Upstream projects do change their own dates. For anything contractual or audit-related, confirm against the vendor's official policy.

A note on accuracy

Support policies are set by each upstream project, and they sometimes disagree with themselves. While researching this site we found cases where a project's own documentation listed a different end-of-life date than the community dataset was tracking. Where that happens, the vendor is authoritative.

For that reason the written explanations on dependency pages describe how a project's support policy works rather than asserting specific dates in prose, so that they cannot drift out of sync with the live release timeline shown alongside them. If you spot a real discrepancy, please report it, ideally to endoflife.date so every downstream user benefits.

Who built this

GetEndOfLife is built and maintained by Sharad Regoti as an independent project. It is free to use, with no paid tier and nothing to upsell.

The method behind every figure is stated on the page that shows it. Support windows are medians rather than averages, so one unusual release cannot skew them, and where there are too few tracked cycles to say anything meaningful the figure is left out instead of estimated. If a number looks wrong, it is worth telling me, because it usually means the upstream data and the vendor disagree.

Following along without an account

If you would rather not sign up, the RSS feed lists dependencies reaching end of life over the coming year. The full index of tracked dependencies is at /tools.