What an iCal file check can tell you
CalendarCheck reads an uploaded, pasted, or publicly reachable iCalendar file on the server and turns its events into a timeline with selected structural observations.
1. Choose a calendar input
Upload a plain-text .ics file, paste its contents, or enter a public HTTPS calendar URL. The current input limit is 1 MB. URL checks use the standard HTTPS port, follow at most two redirects, and are limited to public internet hosts. The server fetches the calendar URL for this one-time check; it does not connect to Airbnb, Vrbo, or Booking.com accounts.
Private feed URLs can function like passwords. Only submit a link you are authorized to use, and treat it as a secret. URL and file content are handled in memory and are not saved to an account or history.
2. Parse the calendar
The parser reads the VCALENDAR structure and its VEVENT entries. It summarizes event start and end times, all-day status, time-zone definitions, and a shortened event title. All-day DTEND values are shown as exclusive end dates, as specified by the iCalendar format.
3. Review findings
The first release checks VERSION and PRODID at calendar level, and UID, DTSTAMP, DTSTART, and date ranges for events. It also flags repeated master-event UIDs and time-zone references without a local definition, and warns about LF-only line endings or overlong content lines. Informational notices describe absent calendar labels or floating local times. Recurring rules are not expanded yet; the master event is shown with a warning. Findings cover selected rules from RFC 5545, not the full specification. A warning does not necessarily mean a calendar application will reject the file.
What a green result does not prove
A readable file does not prove that a booking platform downloaded it, refreshed it promptly, interpreted every recurrence rule as intended, or changed availability. Compare the resulting dates with the platform where you manage bookings. Do not rely on a single automated check to prevent overbooking.
File handling and monitoring
One-time checks are handled in memory and are not saved to a user account or result history. Avoid sharing private guest names, phone numbers, access codes, or other details with a public checker. Account-based daily monitoring and optional email alerts have been implemented, but are not open to the public until account verification, encryption, mail delivery, and server scheduling are configured.