Delete a recurring event in Google Calendar without losing the past

The standing meeting has served its purpose. The project shipped, the person left, the weekly review became fortnightly. Clicking delete brings up a small dialog with three options that look like variations on the same idea, and picking the wrong one has consequences that are not obvious from the wording.

One of those options cannot be undone. Another one removes twelve months of attendance history along with the future. A third thing that looks like deleting is not deleting at all, and is usually what the situation actually calls for.

The three options, and which one can be taken back

Google Calendar names the scopes slightly differently depending on the screen, so both wordings are worth recognising.

Option	Also shown as	What it removes	Recoverable from trash
This event	Only this instance	The single occurrence clicked	Yes
This and following events	All following	That occurrence and every later one	No
All events	All events in the series	Every occurrence, past ones included	Not stated as covered by the warning

The second row is the one to be careful with. Google states the limitation directly rather than burying it.

Important: If you choose This and following events or All following, the deleted events are not moved to the trash and can't be restored. Source: support.google.com

Everything else that gets deleted from a calendar sits in that calendar's trash for 30 days, where it can be restored or removed for good. Truncating a series from a given date forward is the exception, and there is no confirmation step that says so at the moment of clicking.

The third row carries a different kind of loss. A series deleted in full takes the past with it, which means the record of who attended, the notes in the description, and any files attached to individual occurrences. For a personal habit that record is worthless. For a client review, a board meeting or a one to one, it is often the only account of what was discussed and when.

Ending a series is usually what was wanted, not deleting it

For a meeting that ran and then stopped running, the accurate change is not a deletion at all. It is a change to the repeat rule so the series ends on the last date it actually happened.

The path is the same as creating a repeat. Open the event, click Edit, click the dropdown next to "Does not repeat", and set when the repeat ends. On saving, Calendar asks which occurrences the change applies to. The past occurrences stay exactly as they were, with their guests and their descriptions, and nothing new appears on the grid after the chosen date.

What that does underneath is add an end boundary to the recurrence rule. Google's own API documentation shows the pattern, in the form RRULE:FREQ=WEEKLY;UNTIL=20110701T170000Z, which is the iCalendar syntax defined in RFC 5545. A series with an end date is a complete, well formed record of something that used to happen weekly and now does not. A deleted series is an absence, and six months later nobody can tell whether the meeting stopped or was never there.

There is a second reason to prefer ending over deleting. Deleting an event that you created takes it off the calendars of everyone invited, not only off yours. For a series with six guests, a full delete removes the history from six calendars, and none of them get a say in it.

The options vanish when the series belongs to someone else

A guest looking for those three choices will not find them. Google is explicit that the scope options appear for a series you created, and that if someone else created the repeating event, those options are not offered. What a guest gets instead is Remove, or Remove from this calendar, and that action tells the organiser the invitation is declined.

That difference matters when the goal is narrow. A guest who wants out of the Thursday slot from next month onward has no mechanism for it. The realistic options are to decline the individual occurrences that are no longer wanted, leaving the series in place, or to remove the whole thing and lose the occurrences that are still relevant.

The third option, and the one worth choosing more often, is to ask the owner to put an end date on the series. It takes them fifteen seconds, it fixes the problem for every guest at once, and it leaves everyone's history intact. A calendar full of declined occurrences looks to the organiser like an attendance problem rather than a scheduling one.

Deleting occurrences one at a time has a real cost

The workaround that occurs to most people is to delete the unwanted occurrences individually. It works, and Google warns against it in strong terms in the developer documentation.

Warning: Do not modify instances individually when you want to modify the entire recurring event, or "this and following" instances. This creates lots of exceptions that clutter the calendar, slowing down access and sending a high number of change notifications to users. Source: developers.google.com

The mechanism behind that warning explains why it is not merely a style preference. A recurring event is stored as one event carrying a recurrence rule. Occurrences are generated from that rule and are not stored separately. The moment one occurrence is changed or cancelled, it becomes an exception, which is a stored record attached to the parent series. Cancelling a hundred occurrences one at a time creates a hundred exceptions, and every one of them is data the calendar has to carry and send to every client and every guest.

That is the origin of a symptom people report without understanding it: a calendar that gets slow, or a colleague receiving a stream of update emails from a meeting that nobody thinks is being edited. Fifty individual deletions on a shared series is fifty change notifications, subject to each recipient's own notification settings.

It also helps to know that an apparently endless series is already finite. Repeating events in Google Calendar have a limit of 730 occurrences, so a daily meeting created with no end date runs about two years and then stops. Anyone reaching for individual deletions on a long series is often deleting occurrences that a single end date would have handled.

When the meeting is moving rather than ending

A large share of recurring event deletions are not really deletions. The Monday review is moving to Wednesday, the hour is becoming forty five minutes, the room is changing. The instinct is to delete the old series and build a new one, and that instinct costs the history for no benefit.

Calendar supports editing a series with the same three scopes as deleting it. Open an occurrence, click Edit, change the day, the time or the location, then save and choose which occurrences the change applies to. Choosing "This and following events" splits the series at that point: earlier occurrences keep the old day and time, later ones take the new ones, and the guest list and description carry over without being retyped.

The practical result is one continuous record of a meeting that changed, rather than two unrelated series with a gap between them. Reports built on calendar data treat it as one thing. Anyone looking back at the calendar in a year can see when the change happened.

Delete and recreate has two further costs worth naming. Every guest is re-invited from scratch, so their earlier responses are gone and each has to accept again. And any occurrence that had been individually adjusted, a skipped week or a room change for one date, is lost, because those adjustments belong to the old series.

The one case where recreating is the honest answer is a series whose entire character has changed: different attendees, different purpose, different length. At that point it is a new meeting, and the old one should get an end date rather than a deletion.

The delay after deleting, and the devices that keep showing it

A deletion that looks like it failed usually did not.

Google notes that after an event is deleted it may take a while before it disappears from other people's calendars, and that if you delete an event you do not own, the event owner may need to delete it for it to leave everyone's calendar. So a cancelled meeting that still shows on a colleague's screen an hour later is normal, and an event removed by a guest was never going to clear for the group.

On other devices belonging to the same account, a manual sync is the fastest fix. On iOS that means closing and reopening the Calendar app. On Android it is the refresh action in the Google Calendar app's menu. Both exist because devices poll on their own schedule rather than being pushed every change instantly.

On a Mac the same rule applies to whichever application shows the calendar. An application holding read and write access to Google Calendar removes the event at the source, so the change is already in Google by the time the browser is checked. One that only subscribes to a published address shows a cached copy and lags. Which mode a given calendar application uses is worth checking before blaming Google for a stale grid, and Features lists that distinction for a native Mac client.

Getting back a series that was already deleted

For anything other than a "this and following" deletion, the trash is the first place to look. It is reached from the settings menu in the top right of Google Calendar, it is per calendar rather than global, and deleted events stay there for 30 days before going for good. Anyone with "Make changes to events" or "Make changes AND manage sharing" permission on that calendar can both delete events and restore them from its trash, which is worth remembering on a shared team calendar where the person who deleted something is not necessarily the person who has to fix it.

For a truncated series there is no trash entry, and the only route back is a copy made beforehand. Google Calendar exports a single calendar as one .ics file, and all calendars at once as a .zip containing one .ics each, from the import and export panel in Settings. Taking that export before a large cleanup costs a few seconds and is the only real insurance for the irreversible option.

Note that an export needs the "Make changes and manage sharing" permission on the calendar, and is only available in a browser rather than the mobile app, so it is not something that can be done in a hurry from a phone after the fact.

What to change first

Before opening the delete dialog, decide whether the series should stop or should never have existed. If it ran and is now over, set an end date on the repeat instead, which keeps the past and removes only the future. Keep "This and following events" for cases where losing those occurrences permanently is acceptable, and take an export first when it is a shared calendar.

For day to day work, the more useful change is a calendar that shows the scope it is about to affect before the click lands. Caltimate confirms the scope on every drag and delete of a recurring event on a Mac.