Track support windows by keeping one register of every runtime, framework, operating system and database you run, with its version, owner and vendor end date, and by checking it automatically against a calendar. Alert at fixed lead times, such as 180, 90 and 30 days, so a date is never a surprise.
Why spreadsheets rot
A spreadsheet works for a week. Then someone upgrades a service and forgets to edit the row. Dates move. New services never get added. Within a quarter nobody trusts it.
The fix is to make the register come from the same places your systems already declare versions: build files, Dockerfiles, infrastructure code and SBOMs. A person then only maintains the exceptions.
What a useful register holds
| Field | Example | Why |
|---|---|---|
| Product and cycle | PostgreSQL 14 | The unit vendors use for dates |
| Where it runs | billing-db, prod | So the owner knows what is affected |
| Owner | team name | Somebody must decide |
| Vendor end date | 12 Nov 2026 | The deadline |
| Source of the date | link to vendor page | So reviewers can verify |
| Decision | upgrade by Sept, or exception | The action |
Where to get the dates
The vendor's own page is the authority. Examples are the Python developer guide, the PostgreSQL versioning page and the .NET support policy. A community calendar such as endoflife.date collects many products in one place with a JSON API, which suits automation. Use it to find dates and then link the vendor page as the source.
Some projects mark future dates as scheduled. The Python guide says dates in italics can be adjusted. Re-read the source on a schedule instead of copying a date once.
Set up the checks
- Scan repositories and images weekly to rebuild the version list.
- Match each cycle to a calendar entry by script.
- Raise a ticket at 180 days out for each match, assigned to the owner from your repository ownership file.
- Raise a second alert at 90 days and a page to the manager at 30 days.
- Close the ticket only when the version changes or an exception is approved with an end date.
- Review exceptions monthly. An exception without an expiry is a decision nobody made.
Lead times that work
Small libraries can move in days. A database major version or an operating system upgrade needs a rehearsal and a change window. Pick lead times from your slowest upgrade, not your fastest. If a Postgres major upgrade takes you three months, 90 days out is too late.
Try it yourself
Watch how the monitoring view surfaces changes over time. Look for what triggers a new finding on a component that has not changed.
Click through it at your own pace, or open it full screen.
Quick check
Who should own an end-of-life date?
The team that runs the service. A central group can maintain the calendar, but the owner decides and schedules the work.
Is a calendar reminder enough?
It is a start, but it breaks when the person leaves. Tie alerts to a ticket queue and a team.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and continuous scanning give you the always current component list this process needs. The free scan shows what one repository contains.
Sources
- Python developer guide: status of Python versions
- PostgreSQL versioning policy
- Microsoft .NET support policy
- endoflife.date
Last reviewed: 19 October 2026.
