We check the dates. Here's the proof.

EOL dates drift: vendors revise them after release, projections harden into “facts,” and errors propagate across every site that republishes them — ours included. So we cross-check our highest-impact products against each vendor's official lifecycle documentation, publish corrections the moment a vendor's page says otherwise, and label honestly when a vendor publishes no dates at all. This page is regenerated from our verification records at every build.

Machine-readable version: /verification.json

Published corrections

Where a vendor's official documentation says something newer or different than the community dataset we build on, we show the vendor's date and record why. We contribute these findings back to the endoflife.date project as we confirm them — its maintainers welcome upstream contributions, and a correction that lands there fixes the whole ecosystem, not just our site.

Vendor-verified products

Each product below was checked against the linked official vendor lifecycle page on the date shown. Verified products display a ✓ provenance line on their pages.

Honestly unconfirmed

Some projects publish support policies but no per-version dates (Redis, React, Docker Engine, NGINX, GitLab, Jenkins, WordPress). Dates we show for them are policy-derived and labeled accordingly — we do not claim vendor verification we can't demonstrate.

Methodology

Verification means a human-reviewed comparison of our published dates against the vendor's own lifecycle documentation — not a blog post, not a mirror, the primary source. Base data comes from the open-source endoflife.date project plus vendor lifecycle pages; risk scores, verification, and corrections are our own layer. Verification coverage expands in ongoing batches, prioritized by product impact. Found an error? The fastest fix for everyone is a report to the upstream project — or check any date yourself with the EOL Checker.