Software EOL & Support Monitor

Track documented software lifecycle dates before an unsupported release becomes an emergency migration.

This Apify Actor checks an explicit watchlist of software products and release cycles against the public endoflife.date API v1, classifies upcoming or passed lifecycle dates, and compares the documented fields with a persistent prior snapshot. Schedule it daily or weekly and connect the dataset to your existing Apify automation, webhook, Slack, email, or data pipeline.

Unofficial: this community Actor is not affiliated with, sponsored by, endorsed by, or maintained by endoflife.date or any software vendor.

Who it is for

• platform and SRE teams maintaining runtimes, databases, operating systems, and infrastructure tools;
• MSPs tracking lifecycle risk across customer environments;
• IT asset and vulnerability teams that need a compact lifecycle feed;
• engineering managers planning upgrades before active support or maintenance ends.

What one run does

For each exact product/cycle target, the Actor:

1. fetches the product once from the fixed public https://endoflife.date/api/v1 origin;
2. finds the requested release cycle;
3. reports documented release, active-support, maintenance, LTS, EOL, and latest-version facts;
4. assigns a conservative lifecycle_status using your warning window;
5. compares the fields with the previous successful run in a named key-value store;
6. writes one structured dataset row per target.

The Actor does not inventory your systems, decide whether a system is compliant, or infer semantic-version ordering. If you provide deployedVersion, it only checks exact equality with the latest version documented by the source.

Input

{
  "monitorId": "production-platform-stack",
  "targets": [
    {
      "product": "python",
      "cycle": "3.13",
      "label": "Payments API runtime",
      "deployedVersion": "3.13.14"
    },
    {
      "product": "postgresql",
      "cycle": "16",
      "label": "Primary database"
    },
    {
      "product": "ubuntu",
      "cycle": "24.04",
      "label": "Application hosts"
    }
  ],
  "warningDays": 180,
  "timeoutSeconds": 30,
  "maxConcurrency": 3
}

Field	Required	Meaning
monitorId	yes	Stable ID that isolates this watchlist's persistent baseline. Use the same value on scheduled runs.
targets	yes	1–100 unique product/cycle objects, with no more than 50 unique products.
targets[].product	yes	Exact lowercase product slug used by endoflife.date, such as python, nodejs, postgresql, or ubuntu.
targets[].cycle	yes	Exact release-cycle name, such as 3.13, 22, 16, or 24.04.
targets[].label	no	Internal environment, service, owner, or asset label.
targets[].deployedVersion	no	Exact deployed version for an equality-only comparison with the documented latest release.
warningDays	no	0–730 days; defaults to 180. Dates inside this window are classified as approaching.
timeoutSeconds	no	Per-product request timeout from 5–60 seconds.
maxConcurrency	no	1–5 concurrent product requests. A product referenced by several cycles is fetched once per run.

Find product and cycle names on endoflife.date or through its API documentation.

Output

A successful target produces a row shaped like this (values change with the source):

{
  "label": "Payments API runtime",
  "product": "python",
  "cycle": "3.13",
  "status": "unchanged",
  "lifecycle_status": "approaching_end_of_active_support",
  "checked_at": "2026-07-15T08:00:00Z",
  "release_date": "2024-10-07",
  "eoas_from": "2026-10-01",
  "eol_from": "2029-10-31",
  "days_to_end_of_active_support": 78,
  "days_to_end_of_life": 1204,
  "is_lts": false,
  "is_maintained": true,
  "deployed_version": "3.13.14",
  "latest_version": "3.13.14",
  "update_available": false,
  "changed_fields": [],
  "changes": [],
  "state_store_mode": "named_key_value_store",
  "charged_event": "eol_cycle_check",
  "charged_event_count": 1,
  "charge_limit_reached": false
}

Snapshot status

• initial_snapshot — first successful check for this monitorId + product + cycle;
• unchanged — documented lifecycle fields match the prior successful snapshot;
• changed — one or more documented fields changed; inspect changed_fields and changes;
• unknown_product — the source returned no such product;
• unknown_cycle — the product exists, but that exact cycle was not found;
• fetch_error — the bounded upstream request or response validation failed.

Lifecycle status

• maintained
• approaching_end_of_active_support
• active_support_ended
• approaching_end_of_life
• end_of_life
• not_maintained
• lifecycle_unknown

These are mechanical labels derived from source fields and dates. They are not compliance, security, procurement, or upgrade recommendations.

Persistent state

The Actor stores successful snapshots in the explicit named key-value store:

software-eol-support-monitor-state-v1

Keys are SHA-256 digests of monitorId, product, and cycle, so they are valid Apify storage keys and separate independent watchlists. Failed and unknown targets do not overwrite a prior successful snapshot.

Billing behavior

The Actor emits the eol_cycle_check charge event only after it has fetched a valid product record, found the exact cycle, classified it, compared it, and stored the new snapshot. Unknown products, unknown cycles, input rejects, and fetch failures are not charged by this Actor event. It respects the run's Apify maximum-charge limit and stops before processing another paid target when the limit is reached. The current amount is shown on the live Apify Store listing.

Safety and operational limits

• The network destination is fixed to the HTTPS endoflife.date API v1 origin; user-supplied URLs and request headers are not accepted.
• Cross-origin redirects are rejected.
• Responses are capped at 2 MB and 2,000 release records per product.
• Requests use bounded timeouts, concurrency, and retries; 429 and transient server responses receive short capped backoff.
• Inputs are bounded to 100 targets and 50 unique product requests per run.
• The Actor does not need credentials for the upstream API. Do not put secrets in labels or input fields.

Data-source and affiliation notice

Lifecycle data is supplied by the community-maintained endoflife.date project and can be incomplete, delayed, corrected, or different from a vendor's terminology. Its documentation currently labels API v1 as Beta and warns that breaking changes can occur. Always verify material decisions against the relevant software vendor's current documentation and contract. This Actor is an independent, unofficial integration and is not affiliated with, endorsed by, or sponsored by endoflife.date or any monitored vendor.

The endoflife.date API specification identifies the project license as MIT. Source links and upstream timestamps are included in output where available.

Local development

python -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
python smoke_test.py
npx --yes apify-cli validate-schema
apify run --purge

The deterministic smoke test runs the real Actor three times against a bounded local fixture and verifies initial_snapshot → unchanged → changed using persistent local Actor storage.

Deployment

$npx --yes apify-cli push

After deployment, run the default input once, inspect the non-empty dataset, then run it again with the same monitorId to verify the named-store baseline is reused before scheduling production checks.