Google Calendar made your recurring series private, retroactively

The change, in Google's words

On 7 July 2026 the Google Workspace Updates blog published a post about a new calendar sharing permission level. Halfway down, under a subheading, is a change that has nothing to do with delegation and everything to do with any system reading a calendar:

Users can no longer make changes to the visibility of a single event in a recurring series. Any changes to visibility will be applied to all events in the series.

Existing events in a recurring series will be updated to match the strictest visibility setting of any event in that series. In other words, if one event in the series is marked private but the others are not, all events in that series will be changed to private.

• New calendar sharing permission level and changes to recurring event visibility, Google Workspace Updates, 7 July 2026

Read the second paragraph again, because it is the one that matters. This is not a rule about what happens next. It is a rewrite of data that already exists: one private instance anywhere in a series makes the entire series private, including every past occurrence.

The rollout details from the same post:

Rapid and Scheduled Release domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on July 7, 2026

Admins: There is no admin control for this feature.

• New calendar sharing permission level and changes to recurring event visibility, Google Workspace Updates, 7 July 2026

A rollout described as extended, starting 7 July, has had two months to land. The post lists the audience as all Google Workspace customers, Workspace Individual subscribers, and users with personal Google accounts - so this is not an enterprise-only change, and the client whose booking calendar is on a personal Gmail account is in scope too.

There was no migration window, because there was nothing for anyone to migrate. The data was changed in place, and no admin setting existed to opt out of it.

The half the blog post leaves out

The Workspace Updates post is written for people who use Calendar. It never mentions the API. The developer release notes, published the same day, cover what changed for anything integrating with Calendar - and this half is not in the blog post at all:

More restrictive changes propagate: If you change the visibility of one instance of a recurring event to a more restrictive setting (for example, from public to private), the change is propagated to all instances of the recurring event.

Less restrictive changes are ignored: If you attempt to change the visibility of one instance of a recurring event to a less restrictive setting (for example, from private to public), the change is ignored and the visibility remains unchanged. To make a recurring event less restrictive, you must update the parent recurring event.

• Google Workspace release notes, Google Calendar API v3 entry dated 7 July 2026

"The change is ignored" is the sentence to take to your integration. A request that loosens the visibility of one instance does not fail. It is accepted, and nothing happens. If your code checks for an error to decide whether the write worked, it will report success on a write that had no effect, which is the most expensive kind of silence a sync can produce. The same rule now sits in the Calendar API's sharing guide and in a note on the events reference itself, so this is documented behaviour rather than a bug in flight.

The route that does work is stated in the same note: to make a recurring event less restrictive, update the parent recurring event rather than an instance of it.

The half the release notes leave out

Symmetrically, the developer note describes the propagation rule and says nothing about the retroactive rewrite of series that already existed. That sentence appears only on the end-user blog.

So the complete picture exists nowhere in one place:

If your team reads only the developer channel - which is the reasonable choice for an integration team - you learned about a new propagation rule and never learned that history had been edited. If you read only the Workspace blog, you know your calendar changed and have no idea that your booking system's writes are now being dropped.

What this does to an integration

Nothing about the event disappears. The event is still there, still occupies the slot, still returns from events.list. What changes is how much of it any given caller can see, and that depends on the caller's access level rather than on the event.

The Calendar API documents the levels plainly. The sharing guide, on the private value:

The details of this event are only visible to users with at least writer access to the calendar.

• Calendar sharing, Google Calendar API documentation

The ACL reference spells out what the two read-capable roles below that get:

"reader" - Provides read access to the calendar. Private events will appear to users with reader access, but event details will be hidden.

• Acl, Google Calendar API documentation

So the failure mode for a system connected as a reader is not an error and not a gap in the calendar. The events keep arriving; their details are hidden. Whatever your sync was reading out of those events it is no longer reading - for an entire series, including the occurrences it imported correctly last month. Exactly which fields disappear is not enumerated on either page, so check it against one of your own calendars rather than assuming.

One more nuance worth flagging, because it is exactly the kind of thing that turns into an argument at a support desk: the API's own two pages describe private differently. The events reference says "The event is private and only event attendees may view event details", while the sharing guide says the details "are only visible to users with at least writer access". Those are not the same rule, and if your integration's access depends on which one is true, test it against your own calendar rather than reasoning it out from either page.

The new access level, and what it does not fix

The same 7 July release note introduces a role that sounds like the answer:

Generally available: We are introducing a new calendar access level: writerWithoutPrivateAccess. This new level permits read and write access to events that aren't private on a calendar, and shows private events as busy blocks. Users with this role cannot modify or see details for private events.

• Google Workspace release notes, Google Calendar API v3 entry dated 7 July 2026

Note the quantifier: read and write access to events that aren't private. This role exists to let an assistant manage a calendar without reading its private meetings - the delegation use case from the blog post. For an integration whose problem is that a series just became private, it is the wrong direction: it grants less, not more.

The account that keeps working is one with writer or above on that calendar. Which turns this into an access-review job rather than a code change: for every calendar your automation reads, check what role the connected account actually holds.

Finding what was rewritten

There is no report of affected series, no notification, and no admin toggle - so the only way to know is to look. Two things are worth doing on the calendars that matter:

• Enumerate, do not sample. List events over the range your integration cares about and read the visibility field on each. Anything you expected to be default or public and that now reads private is a candidate, and a series returns the same value on every instance now, by design.
• Fix at the parent, not the instance. Google's instruction is explicit: to make a recurring event less restrictive, update the parent recurring event. Any script written before July that loops over instances is now doing nothing, quietly.

And the rule of thumb this change reinforces: a per-instance write to a recurring series is not a reliable operation any more. If a workflow depends on one occurrence differing from the rest, it needs a different design - a separate event, or a single-instance event created outside the series.

What we would do this week

• List the automations and tools that read Google Calendar event details rather than just free/busy, and note which account each one connects as
• Check the ACL role that account holds on every calendar it reads: private event details need at least writer access
• Scan the calendars that matter and read the visibility field on each event, looking for series that are now private and should not be
• Search your codebase for any write that sets visibility on a single instance of a recurring event, and rewrite it to update the parent series
• Stop treating a successful API response as proof: a less restrictive per-instance visibility change is accepted and ignored
• Warn the humans, since this reaches personal Google accounts as well as Workspace domains, and there is no admin control to switch it off
• Where one occurrence must genuinely differ from the rest, create it as a separate event instead of an exception inside the series

This is the shape of vendor change that costs the most to discover late: no error, no notification, no admin control, and data that quietly means something different than it did in June. It is the same failure pattern as a connector that changed under you - except here the platform also rewrote what was already stored, and told two different halves of the story in two different places.

Sources

• New calendar sharing permission level and changes to recurring event visibility - Google Workspace Updates, post dated 7 July 2026, read 25 August 2026. The new "Make changes (see private events as free/busy)" permission level, per-instance visibility changes applying to the whole series, existing series being updated to the strictest setting present in them, "Admins: There is no admin control for this feature", the extended rollout starting 7 July 2026 for Rapid and Scheduled Release domains, and availability to all Workspace customers, Workspace Individual subscribers and personal Google accounts.
• Google Workspace release notes - Google for Developers, Google Calendar API v3 entries dated 7 July 2026, read 25 August 2026. More restrictive per-instance changes propagating to all instances, less restrictive changes being ignored with the instruction to update the parent recurring event instead, and the new writerWithoutPrivateAccess access level permitting read and write access to events that aren't private while showing private events as busy blocks. These entries do not mention the retroactive rewrite of existing series.
• Calendar sharing - Google Calendar API documentation, read 25 August 2026. The visibility values and their meanings, including private details being visible only to users with at least writer access, the same propagate/ignore rule for recurring events, and the limit of up to 6,000 ACLs per calendar.
• Events - Google Calendar API reference, read 25 August 2026. The visibility field, its default of "default", and the descriptions of public, private and confidential - including the wording that a private event's details are viewable by event attendees, which differs from the wording on the sharing guide.
• Acl - Google Calendar API reference, read 25 August 2026. The role values and their descriptions, including reader and writerWithoutPrivateAccess showing private events with details hidden, and writer seeing event details.