EOL Risk Score for a specific version

The release cycle answered. When the request named a patch or build, requested_version and version_matched_by are present too.

Only when the slug sent is an alias of a tracked product (fortigate, weblogic, ios-xe): the slug as sent; product is the tracked slug it resolved to.

Only when the version was resolved to its release line: the version as sent.

Only when the version was resolved to its release line rather than matched exactly.

null when the vendor has published no date, or has only said the line is already end of life (see eol_boolean).

true = end of life with no exact date published; false = not end of life, no date published; null = a date is given in eol_date.

warn = within 180 days of end of life, still supported; unknown = the published date could not be read

true when the vendor still ships fixes today: status active or warn. false for eol and unknown.

Counted to eol_date. When eol_date_precision is month or quarter, that is the period's last day: show the month, not the count.

How precisely the vendor publishes eol_date: day = the vendor names the day; month or quarter = the vendor names only the month (quarter), so eol_date is that period's LAST day, kept for sorting and comparison; display the period ("October 2026"), not the day. null when eol_date is null.

End of the vendor's active (full or standard) support phase for this line, where one is published. The risk score's eol_recency factor reads it. null where none is recorded.

How precisely the vendor publishes support_date: day = the vendor names the day; month or quarter = the vendor names only the month (quarter), so support_date is that period's LAST day, kept for sorting and comparison; display the period ("October 2026"), not the day. null when support_date is null.

How precisely the vendor publishes extended_support_date: day = the vendor names the day; month or quarter = the vendor names only the month (quarter), so extended_support_date is that period's LAST day, kept for sorting and comparison; display the period ("October 2026"), not the day. null when extended_support_date is null.

Present only when a date above is month or quarter precision: which date, the period it stands for, and that it is stored as the period's last day.

EOL Risk Score (higher = riskier)

Present for hardware products whose versions are models: cpe lists only this model's identifiers, never the other models on the vendor page.

Present when cpe_scope is model and no NIST CPE names this model, so cpe is null.

The score card page on endoflife.ai. The cycle is written as the site writes it: every character outside letters, digits, dot, dash and underscore becomes a dash.

Where the served eol_date was read from: the vendor page for a vendor-sourced date, https://endoflife.date for an upstream date, https://endoflife.ai/how-it-works for our own catalog.

End of the vendor's own extended or paid support phase for this line where one is published (Microsoft ESU, Oracle Extended Support, Red Hat ELS, Ubuntu ESM). A line past eol_date may still be covered until this date under that program, unless extended_support_ships_fixes is false. null where none is recorded. The eol_date_source and eol_date_confidence fields describe eol_date only; this date comes from the same lifecycle record but is not covered by them, so confirm it with the vendor before relying on it for a contract.

false where the vendor ships no fixes in the phase that ends on extended_support_date (support services or advice only: Cisco Last Date of Support, Hazelcast Extended Support, Ivanti Customer care, Zyxel End of Life), so a line past eol_date receives no patches from the vendor even though that phase is still open. null where no such statement is recorded.

Where eol_date comes from: vendor-override (set from the vendor's own publication), vendor-fetched (our adapter read the vendor's lifecycle page and it agrees), vendor-verified (a human cross-check covers this version), custom (our own catalog), upstream (endoflife.date only), discrepancy (the vendor page disagrees with the served value; under review). Full report: https://endoflife.ai/verification.json

The vendor page or record the label rests on.

When the label was last established: the vendor feed's read date, the human check date, or the day the correction was applied.

ok = vendor feed read within 14 days and agreeing; fallback = feed older than 14 days (last good value); mismatch = the vendor feed disagrees with the served value; human = a recorded correction or human verification; upstream = endoflife.date only; custom = our own catalog.

How many independent source classes agree with eol_date: the vendor's own feed, a human decision (correction or verification record), the upstream dataset.

high = two or more sources agree; medium = one source; low = the vendor feed disagrees with the served value, or a stale feed is the only source.