A deliberately small inventory
We looked up Node.js 20 and 22, plus Python 3.10 and 3.11, on October 18, 2026. The Actor retrieved all four exact release-cycle observations from endoflife.date. No installed software inventory was scanned.
Two listed end-of-life dates were before the observation date: Node.js 20 at April 30, 2026, and Python 3.10 at October 1, 2026. The source listed Node.js 22 at April 30, 2027 and Python 3.11 at October 31, 2027. These are source-declared dates, and planned dates can be revised. The countdown column uses UTC days as of this observation.
Why a single boolean is not enough
The Node.js 20 row retained isMaintained=true even though its endOfLifeDate was in the past. Preserve that source distinction instead of collapsing it into a single supported/unsupported verdict. The Node.js release page lists version 20 as EOL and discusses commercial support beyond Maintenance LTS. That does not establish whether your organization has such support.
Use the exact date, the support phase and your vendor agreement together. For Python, consult the official version-status table and the linked release schedules. The original extracted records and vendorPolicyUrl fields are included in the sample download.
Turn the finding into a useful action
Join product plus cycle to your own service inventory. Add an application owner, the deployed patch version, any commercial support arrangement and a proposed migration date. Review the vendor policy before prioritizing work. This is a support-planning input, not evidence of exploitable vulnerabilities or compliance.
Reproduction and limits
The four-cycle input and saved observations are downloadable. A later run will recalculate daysToEndOfLife and may see source corrections. This run had comparison history disabled, so it proves no date changed since an earlier observation.
The Actor’s upstream source is endoflife.date, a community-maintained lifecycle dataset. Publisher policies remain important corroborating evidence. Four chosen cycles do not represent all runtimes in use or the distribution of production deployments.