← All posts

End of life vs extended support: which date counts?

StackClock team ·

"End of life" sounds final. Often it is not. A lot of runtimes, operating systems and frameworks have a second date after it: extended support. If you plan around the wrong one, you either panic too early or get caught out too late.

Here is the difference, and which date we think you should plan around.

What end of life (EOL) means

End of life, or EOL, is the date the people who make the software stop fixing it. No more security patches and no more bug fixes, and usually no more help when something breaks.

For open source projects this is the community's date. It is the one you see on endoflife.date and on most project release pages. After it, a new vulnerability in that version stays open.

What extended support means

Extended support is paid or vendor-run cover that carries on after the community stops. You sometimes see it called ELS (extended lifecycle support) or ESM (expanded security maintenance). A few examples:

  • Ubuntu Pro adds years of security patches to an LTS release.
  • Red Hat sells extended lifecycle support for older RHEL versions.
  • Cloud providers can charge extra to keep an old database or function runtime running past its normal date.

Look at a real release. Ubuntu 26.04 LTS reaches end of life on 29 May 2031. With Ubuntu Pro's expanded security maintenance it is covered until 23 April 2036. That is five more years, but only if you pay for it and turn it on.

Which date should you plan around?

We say the community EOL date. Here is why.

  1. Extended support is not automatic. Somebody has to buy it, enable it and keep paying.
  2. It often covers the operating system or runtime, not every package you installed on top.
  3. It is a safety net, not a plan. Staying on an old version costs more every year.

So treat the EOL date as your deadline. Treat extended support as extra time you can buy if the upgrade slips. If you already have a contract, you know which date is real for you. Most teams do not have one.

How StackClock shows both

We show both dates, and we keep them easy to tell apart.

  • The end of life date is the headline. It is the one that becomes a deadline on your timeline, with reminders 60, 30, 14, 7 and 1 days before.
  • The extended support date shows next to it in violet, so you never confuse it with the red "past end of life" or the amber "due soon".

You see it on your stack page when a dependency, Docker image or runtime in your workspace has extended support. It is also on our public end-of-life pages, for example Ubuntu, where each release shows an "Extended until" badge.

One honest limit: our dates come from endoflife.date. Extended support sold by third-party vendors that it does not list is not shown yet.

Check your own stack

Do you know which of your runtimes are past end of life, and which only look fine because someone pays for extra cover?

Paste a package.json, requirements.txt, go.mod or Dockerfile into the free stack check. You get deprecated packages, end-of-life versions and known vulnerabilities in a few seconds, with no sign-up.

When you want the dates to remind you before they hit, start free, import your stack into a workspace and we watch it every day.