Software Support Deadline Monitor

Turn a software portfolio into a release-cycle support watchlist. Get separate active-support, end-of-life, and extended-support dates; exact before/after changes; approaching-deadline transitions; and an importable calendar. Every record links back to its public source.

Built for platform teams, IT service providers, and software portfolio owners who need to review support deadlines regularly. The data comes from the public endoflife.date v1 API. The paid value is bounded collection, consistent exports, explicit comparisons, and Apify workflow integration. endoflife.date itself is freely accessible.

The upstream v1 API is Beta and can change. This Actor validates the expected schema and fails clearly on incompatible responses; it does not promise API stability.

Quick start

Use this input in Apify's input editor:

{
  "watchlist": ["nodejs:22", "python:3.13", "postgresql:17"],
  "maxItems": 100,
  "maxRequests": 20,
  "deadlineWindowDays": 90
}

Use nodejs:22 for the exact cycle named 22; use nodejs for every documented Node.js cycle. Find product slugs and cycle names on endoflife.date. A version such as 22.14.0 is not automatically mapped to a cycle. No approximate version matching occurs.

On the first run, records have changeType: "baseline". To compare a later run, download the first run's default key-value store SNAPSHOT JSON and paste its entire object into previousSnapshot while keeping the same watchlist. A snapshot from another Actor or watchlist is rejected. Runs do not discover or overwrite another run's snapshot automatically. A recurring Apify workflow must explicitly pass the prior snapshot into each run.

What you receive

Each dataset row represents one canonical product and release cycle. Download the dataset as JSON, CSV, or Excel from Apify. Nested changes and deadline data are most useful in JSON.

Field	Meaning
id	Stable canonical product:cycle identity, such as nodejs:22
product, productLabel, productCategory	Source product identity
releaseCycle, releaseLabel, codename, releaseDate	Exact release-cycle details
activeSupportEnded, activeSupportEndDate	Source active-support status and end date
eol, eolDate	Source end-of-life status and date
extendedSupportEnded, extendedSupportEndDate	Extended support; null when unknown or not applicable
maintained	Whether any source-listed support remains, including commercial support
isLts, ltsFrom	Source long-term-support status and start date
latestVersion, latestReleaseDate, releaseNotesUrl	Latest documented version within the cycle
supportLabels	Product-specific meanings of the active, EOL, and extended phases
custom	Sorted source-specific string/null fields, when present
deadlines	Known phase deadlines as {kind,date}; unknown dates are omitted
deadlineStatus	Each deadline's UTC day difference and urgency bucket
changeType, changes	Baseline, added, changed, or unchanged, with exact field-level before/after values
thresholdCrossings	A known unchanged deadline moving between urgency buckets since the prior snapshot
sourceUrl, sourceApiUrl, releasePolicyUrl	Source page, API endpoint, and vendor policy link
sourceGeneratedAt, sourceLastModifiedAt, sourceSchemaVersion	Source provenance, distinct from this run's observation date

The default key-value store also contains:

• OUTPUT: completion status, request counts, comparison counts, limits, and diagnostics.
• SNAPSHOT: a bounded baseline suitable for previousSnapshot on a later run.
• DEADLINES.ics: an all-day calendar of the known deadlines in delivered records.

Calendar dates use the published date without inventing a time zone or time of day. Calendar applications differ in how they handle repeated imports; use the stable event identifiers when building an integration.

Interpret support correctly

An EOL release can still have maintained: true if the source lists extended or commercial support. This does not mean the software remains covered by free upstream security updates or that your organization owns a support contract. Read supportLabels and the vendor policy before making an upgrade decision.

Booleans come from the source's generation time. asOfDate controls countdowns and threshold calculations; it does not retrieve a historical upstream response or recompute the source's booleans. Date changes are reported in changes; threshold transitions concern the same deadline date across observations.

The Actor preserves nulls instead of inventing support dates. It never infers vulnerabilities, installed versions, license entitlement, or upgrade compatibility. It collects no product-description prose, personal contact data, or credentials.

Inputs and bounds

Input	Default	Bounds and behavior
watchlist	Node.js 22, Python 3.13, PostgreSQL 17	1–50 entries, at most 25 distinct products; duplicates removed; an entire-product entry overrides its cycle-specific entries
maxItems	100	1–5,000 delivered release-cycle records
maxRequests	20	1–200 HTTP attempts, including retries and redirects
requestIntervalMs	1,000	500–60,000 ms between requests; sequential collection
requestTimeoutSecs	30	5–60 seconds per request
maxRetries	2	0–3 retries for transient failures
deadlineWindowDays	90	1–730 days; governs urgency buckets, not source filtering
asOfDate	Current UTC date	Real YYYY-MM-DD date for deterministic countdowns
previousSnapshot	None	Matching Actor/watchlist snapshot, at most 2 MiB and 5,000 records

Only https://endoflife.date/api/v1/products/{slug}/ is requested. One product request supplies every selected cycle for that product. Vendor policies and release notes are returned as links and are never fetched. No bulk /full dump, login, proxy rotation, CAPTCHA bypass, or access-restriction workaround is used. Responses are limited to 4 MiB; only up to three same-host redirects are followed. The HTTP layer applies bounded retries and respects Retry-After within its retry policy. Source responses can add new fields without breaking the Actor; invalid documented field types fail explicitly.

sourceScanComplete: false signals truncation, an exhausted request or billing budget, missing requested cycles, or conflicting duplicate records. Never treat an incomplete scan as evidence that a cycle disappeared. With two complete snapshots, notObservedIds only means previously seen IDs were absent from this query; it does not prove a vendor removed a release. Fix unknown cycles before using a snapshot as a complete portfolio baseline.

Local development and verification

Requirements: Node.js 24 or later and npm. From this Actor directory:

npm ci
npm test
mkdir -p storage/key_value_stores/default
cp examples/input.json storage/key_value_stores/default/INPUT.json
npm start

The start command makes bounded public network requests and writes local Apify storage. It does not publish the Actor. Do not provide an Apify token for local fixture tests. Docker builds use the included Dockerfile and lockfile.

test/fixtures/nodejs.live.json was downloaded from the public API on 2026-10-11. Source tests run offline and cover validation, exact selection, canonical deduplication, unknown phases, bounds, upstream schema failures, and request-budget exhaustion. Modified test variants are synthetic. A live smoke check verifies reachability and current response compatibility; it is distinct from the fixture tests and does not prove every upstream product remains valid.

See examples/input.json and examples/output.json for a concrete input and sample dataset row. The output example is a deterministic rendering of the checked-in fixture, dated 2026-10-11, and is not a current-data guarantee.

Upload and pricing

Create a new Actor in your own Apify account, upload this source folder or push it using the Apify CLI, build it, and run the example with a small limit. Inspect the dataset, OUTPUT, SNAPSHOT, and calendar before publishing to the Store. Keep NOTICE with the source and retain endoflife.date attribution in the listing. No account creation, upload, Store publication, or paid Apify run was performed to prepare this source package.

Approved launch pricing is $0.005 per automatic start billing unit plus $0.005 per delivered cycle ($5 per 1,000 cycle records, plus the start fee). Configure apify-actor-start and apify-default-dataset-item in Apify Console. Apify charges startup automatically; never add a manual Actor.charge() call for it or a duplicate custom start/result event.

Up to and including 1 GB RAM, startup is one unit; higher memory multiplies the count (4 GB means four units). These Actors default to 256 MB and cap memory at 512 MB, so startup is $0.005 within the supplied configuration. At 256 MB, 100 delivered cycles cost $0.505 in event charges; a started zero-result or subsequently failed run can still incur $0.005. Other applicable costs follow Apify's terms.

Each successfully delivered record counts once, including unchanged records. Errors, missing cycles, summaries, snapshots and calendar files create no extra dataset-item charge. The SDK includes automatic startup in its already-consumed budget; the existing runtime checks remaining item capacity before fetching and each delivery. If none remains, it fetches and delivers nothing. OUTPUT.billing describes this item-cap check, not the complete Apify bill.

This pricing is an approved launch choice, not proof of demand or profit. See PUBLISHING.md and examples/pricing.json for event settings, arithmetic examples, and budget behavior.

Source and reuse

The API's OpenAPI specification declares the MIT License. The public robots.txt allowed all paths when checked on 2026-10-11. The specification documents HTTP 429 and Retry-After but does not state a numeric request quota. Defaults are deliberately modest. Preserve the included upstream notice when redistributing the fixture or substantial source data. Product logos and Wikipedia-derived descriptions are not included. This Actor is independent of endoflife.date and the software vendors.