RHEL and OpenShift Lifecycle Intelligence: Dates, Sources and API

By Scott Bissett  ·  Published: September 22, 2026  ·  Reference  ·  Dates on this page are served from data and re-read from Red Hat daily

Every Red Hat Enterprise Linux and OpenShift Container Platform date on this page comes from Red Hat's own Product Life Cycle Data API, is re-read every day, and is served with its source and verification day. This is the reference for teams that need those dates inside a tool rather than on a web page: a CMDB reconciliation, a CI gate, a compliance report, or an AI agent asked "is this RHEL version still supported?" The RHEL end-of-life guide explains what each phase means and what to do when one ends; this page is about where the dates come from and how to get them programmatically.

1. Where the dates come from

Red Hat publishes lifecycle phases through the Product Life Cycle Data API, the data behind its Product Life Cycles pages. A vendor adapter reads that API daily for each product and maps the phases Red Hat names to the fields the endoflife.ai API serves:

Three sources are compared at every build before a date is served: the vendor read, the upstream endoflife.date value, and any recorded human decision. When they agree the API reports eol_date_confidence: "high". When the vendor read disagrees with what is served, the vendor page decides: the change is applied on the second consecutive read, recorded with its source and applied-on day, and published on the accuracy page. Red Hat's policy page states that ELCP replaces the ELS offering beginning with RHEL 8.10 on June 1, 2029, which is why the RHEL 8 extended date below runs four years past its maintenance end.

Red Hat's API carries RHEL 8, 9 and 10. RHEL 7 is not in it; its dates are held from Red Hat's policy pages and covered in the RHEL guide.

2. RHEL 8, 9 and 10

Full support is when new features and hardware enablement stop. Maintenance support is when standard security and bug fixes stop, and it is the date status and the risk score turn on. The extended column is a paid add-on for the final minor release only, which is why extended_support_available is true for these lines and the score's extended-support factor is zero for them.

3. OpenShift Container Platform 4.16 to 4.22

Red Hat's OpenShift life cycle policy designates even-numbered minor releases as EUS releases, and the EUS Term 1 phase follows the maintenance phase for those releases. Odd-numbered minors have no EUS phase, so extended_support_date is absent for them and extended_support_available is false. Term 2 and Term 3 add-ons are not recorded.

4. One request, in full

The RHEL 9 score card, exactly as the API returns it today. Two request-time fields, days_until_eol and generated_at, are left out because they change every day.

curl https://api.endoflife.ai/v1/score/rhel/9

{
  "product": "rhel",
  "version": "9",
  "latest_release": "9.8",
  "release_date": "2022-05-18",
  "eol_date": "2032-05-31",
  "status": "active",
  "score": 50,
  "grade": "C",
  "grade_label": "Elevated risk",
  "band": "Medium",
  "factors": { "eol_recency": 0, "attack_surface": 30, "cisa_kev_exposure": 20, "extended_support": 0 },
  "extended_support_available": true,
  "extended_support_date": "2036-05-31",
  "score_card_url": "https://endoflife.ai/score/rhel/9",
  "product_url": "https://endoflife.ai/rhel",
  "cpe": ["cpe:2.3:o:redhat:enterprise_linux"],
  "eol_date_source": "vendor-fetched",
  "eol_date_source_url": "https://access.redhat.com/product-life-cycles/?product=Red%20Hat%20Enterprise%20Linux",
  "eol_date_verified_at": "2026-09-17",
  "eol_date_status": "ok",
  "eol_date_agreement": 3,
  "eol_date_confidence": "high",
  "methodology_url": "https://endoflife.ai/risk-score",
  "data_source": "https://access.redhat.com/product-life-cycles/?product=Red%20Hat%20Enterprise%20Linux"
}

Reading it: eol_date is the maintenance support end; extended_support_date is the paid extension; eol_date_source says the served date came from the vendor read; eol_date_source_url is the Red Hat page to check it against; eol_date_verified_at is the last day it was re-read; eol_date_agreement: 3 means all three sources agreed. The score's cisa_kev_exposure factor is the live join against the CISA Known Exploited Vulnerabilities catalog for the product's CPE. The methodology page defines each factor and its points.

The whole product in one call: curl https://api.endoflife.ai/v1/product/rhel returns every RHEL major with the same fields. /v1/product/red-hat-openshift does the same for OpenShift minors.

5. Whole-estate checks

A list of RHEL and OpenShift versions from a CMDB or an inventory export goes to the batch endpoint in one request:

curl -X POST https://api.endoflife.ai/v1/batch \
  -H "Content-Type: application/json" \
  -d '{"products":[{"slug":"rhel","version":"8"},{"slug":"rhel","version":"9"},{"slug":"red-hat-openshift","version":"4.20"}]}'

Each result carries the same date, source and score fields as the single-version call. Anonymous requests and free keys take 5 items per call; Starter keys 25; Pro keys 50. Application-layer inventories (the Java, Node, Python and container components running on those hosts) go to POST /v1/sbom as a CycloneDX or SPDX document and come back annotated per component.

For agents, the MCP server exposes the same data as tools: check_eol, get_risk_score, get_product_lifecycle, scan_stack, get_kev_exposure, get_upcoming_eol, get_upgrade_path and check_sbom. The tools read the same served data as the REST API, so an agent gets the same dates and the same source fields to cite.

6. Running it on RHEL 9 and 10

Nothing has to be installed to use the REST API; it is an HTTPS call from any host. The MCP server has two forms. The hosted endpoint at https://mcp.endoflife.ai needs only an MCP client that speaks remote MCP, or the mcp-remote bridge for clients that do not:

{
  "mcpServers": {
    "endoflife": { "command": "npx", "args": ["mcp-remote", "https://mcp.endoflife.ai"] }
  }
}

The same server runs locally over stdio from the endoflife-mcp npm package on Node.js 20 or later. endoflife.ai is validated on RHEL 9 and RHEL 10 in its Red Hat Ecosystem Catalog listing. Source, licence and the health and server-card endpoints are in the repository README.

7. Production keys and support

Anonymous calls (100 a day) and free keys (500 a day) are for evaluation. Production use runs on a paid key issued the minute you check out: Starter at $79 a month gives 10,000 requests a day and 25 items per batch or SBOM call; Pro at $199 a month removes the daily cap and takes 50 per call. Get an API key. Questions go to [email protected] and are answered in writing, with a sample response for your RHEL versions if that helps.

Frequently asked questions

Related

• RHEL End of Life & Support Options — what each phase means and the four options when one ends
• RHEL product page and OpenShift product page — every version with its live score
• SBOM enrichment walkthrough — the application layer, component by component
• How we verify our dates — sources, confidence and the disagreement log
• API reference and MCP server