Google Calendar “Processed Zero Events”: What to Check

If Google Calendar says “Processed zero events,” check the destination calendar before trying again. Google documents that a second click on Import can produce this message after the first import succeeded. If the events are absent, inspect the downloaded file and try a small control file in a separate test calendar (Google import troubleshooting, checked November 5, 2026).

Key Takeaways

• A zero-events message does not, by itself, prove the file is empty or damaged.
• Confirm the account, destination calendar, and dates before editing the source.
• Compare a simple control file with the failing export through the same import route.
• Count event records separately from recurring occurrences.

First, look for an event that should be there

Choose one distinctive event from the source, including its date and time. Search for its title in the account where you imported the file. Make sure the destination calendar is visible, and inspect the event's calendar assignment.

Do this before changing identifiers or importing the export repeatedly. Repeated attempts make it harder to tell which operation created which items. Finding one event confirms that some data arrived; it does not confirm that the entire export transferred correctly.

Record three things: the destination calendar, the import message, and whether that known event exists. These observations distinguish a completed import from a file that still needs investigation.

Check what you actually downloaded

Open a copy in a plain-text editor. If you need help reading the fields, start with opening an ICS file without importing it.

Look for a calendar wrapper and complete event blocks:

| Source observation | What it establishes | Next action | | --- | --- | --- | | HTML, a login page, or an access-denied message | The download is not the intended calendar data | Export again from the source application | | Only tasks or time-zone definitions | There are no event records in those components | Check that you exported the correct calendar | | BEGIN:VEVENT blocks with missing closing lines | The copy may be truncated or malformed | Obtain a fresh export before attempting repairs | | Complete event blocks | Event records are present | Check dates, identifiers, and parsing diagnostics |

A text search for BEGIN:VEVENT is an initial inventory, not a validity check. A recurring master can generate many dates from one record, and an exception can add another record for the same series. A raw record count therefore need not match a calendar's displayed item count.

An otherwise empty VCALENDAR wrapper is useful as a negative diagnostic example, but it is not a valid event-export control: RFC 5545 requires calendar components inside the object (iCalendar object structure).

Use one small event as a control

Save the following synthetic example as import-check.ics, using UTF-8 and CRLF line endings. It represents one 30-minute event, not an invitation.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CalendarLint//Import Check//EN
BEGIN:VEVENT
UID:import-check-20261110@example.test
DTSTAMP:20261105T000000Z
DTSTART:20261110T140000Z
DTEND:20261110T143000Z
SUMMARY:Calendar import check
END:VEVENT
END:VCALENDAR

The expected parsed values are November 10, 2026, 14:00 to 14:30 UTC, with the title “Calendar import check.” A calendar displaying another time zone can show a different hour.

Create a separate calendar for diagnosis. On a computer, use Google Calendar's Settings → Import & Export, select the file, choose that test calendar, and click Import once. This is the file-import route described in Google's import instructions.

Record the actual result. The sample establishes a known input; it does not promise a particular Google response.

Compare the control with the failing file

Use the same account and import route for both files, with separate empty test calendars so an earlier import does not confuse the comparison.

| Observation | Useful inference | What remains uncertain | | --- | --- | --- | | The control imports; the export does not | Investigate the export's contents and size | Which property or component causes the failure | | Neither imports | Investigate the route, account, and control-file save format | Whether the original export also has defects | | The export imports into a fresh calendar | Inspect the original destination and earlier attempts | Whether every expected occurrence transferred | | Only some expected events appear | Compare missing records with imported records | Whether the issue is parsing, recurrence, or export coverage |

For a controlled negative comparison, duplicate the sample and remove its END:VEVENT line. A validator should identify broken component nesting. This deliberately damaged copy is a file-level diagnostic aid; it is not a claim that Google always reports a particular error for that defect.

For size problems, measure the actual downloaded file. Google's troubleshooting page specifies a limit of 1 MB or smaller. A large export needs a smaller source export or careful grouping, as explained in splitting a large ICS file.

Repair only what the evidence establishes

In CalendarLint, open and review the saved export, then inspect Source and the reported findings. Confirm whether the known event exists in the file and whether its date matches your expectation.

If a repair is justified, keep the original, save a separate version, and compare the changed fields before downloading. Do not change every UID simply to force another import; that changes event identity and can complicate duplicate handling.

A useful support report contains the exact import message, file size, expected date range, a redacted event record, and the result of the small control test. That gives the source application's support team evidence to investigate.

Verification scope: sources checked November 5, 2026. The control and deliberately damaged variant were checked locally with ical.js 2.2.1. Google account imports were not performed; the comparison table describes diagnostic observations to collect.