ICS Calendar Change Monitor

Keep an event directory or automation workflow synchronized with a public ICS calendar. Reuse the same calendar URL and monitor name to get exact previous/current values when event times, titles, venues, links, statuses or recurring-series rules change.

Unlike a calendar parser or feed merger, this Actor keeps a baseline between runs and produces change records. It works on VEVENT records, identified by UID plus RECURRENCE-ID. Recurring masters and exception records remain separate; it does not expand recurring events into occurrences.

Start

Run the default public UK bank-holiday calendar to inspect the output, then replace it with a public calendar you are authorized to monitor. Save and schedule the same input. The first successful check establishes a baseline; subsequent runs compare against the last successful check. Change monitorName to start independent history.

{"calendarUrl":"https://www.gov.uk/bank-holidays/england-and-wales.ics","monitorName":"default","includeUnchanged":false,"allowEmpty":false}

Change records

BASELINE means present on the first check, not newly created. NEW means newly observed. UPDATED has changedFields and exact previous/current objects. TIME_CHANGED, RECURRENCE_CHANGED, EXPLICIT_CANCELLATION and CANCELLATION_CLEARED are useful signals. An explicit cancellation requires source STATUS:CANCELLED; a missing record is never called cancelled.

MISSING_ONCE means absent on one complete check. NO_LONGER_OBSERVED requires two complete consecutive omissions and is emitted once. Feeds can age past events out or omit records for other reasons; absence does not prove cancellation. UNCHANGED is counted in OUTPUT and optionally returned as rows.

The OUTPUT key-value record always contains counts and timezoneDefinitionsChanged, even when the dataset has no changes. Use eventId for downstream deduplication; delivery is at least once.

Dates retain the source's value type and TZID. All-day end dates are exclusive. Floating times are not represented as UTC. This Actor reports source schedule definitions, rather than computing instants or validating calendar correctness. It ignores DTSTAMP, SEQUENCE, descriptions, attendees and organizers; timezone-definition edits appear in the summary. It does not send invitations, edit calendars or synchronize Google/Outlook accounts.

Limits and history

One public HTTPS calendar per check, maximum 2 MB and 2,000 VEVENT records. Up to three redirects, each checked for public Internet addresses; no credentials, custom ports or private network destinations. Source requests time out after 20 seconds. Parse errors, duplicate UID identities, truncation, oversized responses, HTTP failures and ambiguous METHOD:CANCEL messages fail the check and preserve history. Empty feeds fail by default; enable allowEmpty only for feeds where a complete empty calendar is legitimate. A valid but incomplete feed cannot always be detected.

Named history is isolated by the running user, Actor, URL and monitor name. Deleting its named storage resets the baseline. Use only one concurrent run per monitor. A best-effort five-minute lease detects overlapping checks, but is not an atomic storage transaction; real simultaneous contention is not guaranteed safe. Interrupted output/billing/history commits can repeat delivered changes and charges on retry.

Pricing

$0.01 per successful calendar check, including baseline and unchanged checks. One custom calendar-check event; no automatic startup or per-row charge. Platform usage is included. Set maximum run charge above $0.01; suggested default $0.05. Failed source/parser/output checks do not trigger this custom event. Billing occurs after output and before history advances. The Apify Pricing tab is authoritative.

Public calendars only. Do not supply private calendar subscription tokens, secret URLs or attendee information. This is an independent tool, unaffiliated with the source publisher or calendar providers. Open an Issue with a public reproducible feed and run ID; keep secrets out of public Issues.