Free busy in Google Calendar: what other people can see of your day

Free busy is the setting people configure once, forget, and then misread for years. Somebody outside the company reports seeing nothing at all. A colleague sees a solid wall of grey. A scheduling tool proposes a slot that is obviously occupied. All three are the same mechanism behaving correctly under different settings, and none of them are bugs.

Google Calendar decides what another person sees about a given hour using two independent controls plus, for anyone outside the organisation, a third layer that only an administrator can touch. Sorting out which one is responsible takes about five minutes once the layers are separated.

What free busy actually is

Underneath the interface, this is one property per event. RFC 5545, the iCalendar standard, defines TRANSP for it. Events that consume real time are recorded as OPAQUE, "allowing them to be detected by free/busy time searches", and events that do not are recorded as TRANSPARENT, "making them invisible to free/busy time searches". The default value is OPAQUE.

Google's own API documentation names the interface control for the same field directly. The transparency property is described with "opaque" as the default value, the event blocking time on the calendar, and the note that this "is equivalent to setting Show me as to Busy in the Calendar UI". The other value, "transparent", is the Free setting.

Whether the event blocks time on the calendar. Optional. Possible values are: 'opaque' - Default value. The event does block time on the calendar. This is equivalent to setting Show me as to Busy in the Calendar UI. 'transparent' - The event does not block time on the calendar. Source: developers.google.com

So free busy is not a privacy setting. It is a statement about whether an hour is spent. A block of focus time marked Free is genuinely invisible to everyone hunting for a slot, no matter how serious the work in it is. That single field explains most complaints about people booking over protected time.

The two dials that decide what a viewer sees

The first dial is per calendar, set under sharing. Google Calendar offers five permission levels, and only the first restricts a viewer to availability:

Permission level	What the other person can see	Can they edit
See only free/busy (hide details)	Only the hours marked as busy. No titles, times of day detail, places or descriptions	No
See event details	Names, times, locations and descriptions	No
Make changes (see private events as free/busy)	Details of events that are not private, availability only for private ones	Yes, except private events
Make changes and see event details	Full details, plus who else has access	Yes
Make changes and manage sharing	Everything, including the ability to share the calendar onward	Yes

The second dial is per event, set in the event itself. The options are Default visibility, Public and Private. Default follows the calendar's sharing setting. Public shows full details to anyone who can see the calendar at all, overriding the calendar level setting for that one event. Private restricts details to the organiser and to people with make changes access or higher.

The interaction is the part worth memorising. To a viewer who only has free busy access, a Default event and a Private event look identical: a block labelled Busy with nothing readable in it. Marking an event Private therefore changes nothing for that audience, and changes a great deal for a colleague who normally sees full details. People who mark sensitive meetings Private to hide them from outsiders are usually hiding them from their own team instead.

Why one person sees Busy and another sees nothing

Availability is not a public property by default. Google's documentation is clear that availability shows up for people who have shared their calendar with the viewer, or who belong to the same organisation, and that is the condition under which the Find a time view in the event editor can show a guest's schedule at all.

That produces three distinct experiences from one calendar. Inside the same Workspace domain, availability is normally visible and Find a time works. For someone at a different company who has no sharing relationship, the same guest row is simply blank, and the event editor cannot say whether the hour is free. For a personal Gmail account with nothing shared, the same blank appears.

The consequence for meeting invitations is worth stating plainly, because it is the source of endless back and forth. An invitation sent to an external address is a proposal, not a confirmed slot, and no amount of checking Find a time before sending will change that. The only reliable way to let an outsider land on a genuinely free hour is to let them choose from offered times, either through a booking page or by sending two or three candidate slots and holding them.

Publishing availability to people with no relationship

There is a route that works without any per person sharing. In a calendar's settings, under access permissions for events, ticking the option to make the calendar available to public exposes it to anyone, and the accompanying option restricts that exposure to free busy only rather than full details. Leaving that restriction off means the public sees every title and location, which is a genuinely irreversible sort of mistake.

Two practical notes come with this. Google states that sharing settings can only be edited from a computer, not the mobile app, so this is not a change that can be made in a hurry from a phone. And in a Workspace domain the administrator may have switched public sharing off entirely, in which case the option will not appear and no amount of searching the settings screen will produce it.

There is a middle path that gets overlooked. Instead of publishing a whole calendar, a separate calendar can be created to hold only the blocks that outsiders are allowed to know about, and that one can be published or shared at the free busy level while the main calendar stays entirely private. Events get copied or duplicated into it deliberately. The overhead is real, but for anyone who deals with clients, recruiters or partners regularly, it is the only arrangement that gives outsiders something useful without handing over the shape of an entire working week.

Publishing availability is the right tool for a calendar that exists to be checked, such as a room, a shared resource or a public office schedule. It is the wrong tool for a personal calendar, because the exposure is permanent for as long as the setting is on and there is no audit trail of who looked.

Free busy across company lines

When two organisations run different calendar systems, availability between them is an administrative project rather than a user setting. Google Workspace exposes this as Calendar Interop, configured in the Admin console by an administrator with Calendar privileges.

What it carries is availability by default. Administrators can widen that: the documentation notes that to view event details such as title and location from Exchange and Calendar, a Show event details box has to be checked. It works in both directions, with separate steps for letting Google Calendar display Exchange availability and for letting Exchange users see Calendar availability. On the Exchange side, mailboxes have to be set to Limited details visibility for this to function, and the connection needs internet access on port 443 with valid certificates. Multiple Exchange endpoints can be configured, but only one may be the default.

One date belongs in any planning around this. Google's documentation states that EWS legacy connections will be deprecated on 1 October 2026. Anyone whose cross domain availability currently depends on that connection method has a migration on the calendar, not an optional upgrade.

When software asks the availability question

Scheduling tools do not read a calendar to find a slot. They call a dedicated availability endpoint, and its shape explains several of their quirks. The Calendar API exposes freebusy.query, which takes timeMin and timeMax as RFC3339 datetimes, an optional timeZone defaulting to UTC, and an items list of the calendars or groups to check.

Two hard ceilings sit in that request. calendarExpansionMax has a documented maximum value of 50, and groupExpansionMax a maximum of 100. A tool asked to find a slot across sixty calendars is therefore not doing what the user assumes it is doing, and the failure is silent from the user's side.

The response shape matters just as much. Each calendar comes back as a list of busy ranges under a busy array, where start is the inclusive start of the period and end is the exclusive end. There are no titles, no attendees and no reasons, because none of that is in scope for the endpoint. It can also return per calendar error entries carrying a domain and a reason, which is how a tool discovers that it was never allowed to see one of the calendars it was asked about. A scheduler that ignores those errors will cheerfully treat an inaccessible calendar as a completely empty one.

One more detail of that response trips up anyone building against it. Because the end of a busy range is exclusive, a block that runs to 11:00 and a block that starts at 11:00 are adjacent rather than overlapping, and code that merges ranges with an inclusive comparison will report a conflict where none exists. The same convention appears in the iCalendar standard, where DTEND is defined as the non-inclusive end of an event, so the behaviour is consistent rather than a quirk of one endpoint.

What free busy cannot tell anyone, including its owner

Every mechanism above answers one question: is this hour already claimed. None of them answer the question that actually decides whether a day works, which is whether the gaps between the claimed hours are usable.

A schedule can be entirely truthful at the free busy level and still be impossible. Three meetings in three locations, each marked busy and correctly bounded, with twenty minute gaps that need fifty minutes of travel. Availability data says the day is fine. It contains no notion of the journey, because nothing in the calendar ever recorded it. This is where a desktop calendar that turns addresses into real travel blocks changes the picture, since the travel then occupies time that free busy can see and protect, rather than living in the owner's head. How that is calculated for driving, walking and public transport is described in Travel time, and the rest of what a native Mac calendar can layer on top of a synced Google account is set out under Features.

The second blind spot is deliberate work time. Marking focus blocks as Free makes a calendar look accommodating and invites exactly the double bookings people then complain about. Marking them Busy is the honest signal, and it costs nothing except the discomfort of appearing occupied.

What to change first

Open one heavily booked week and check two things: whether the recurring blocks that are supposed to protect working time are set to Busy rather than Free, and whether the calendar's sharing level says free busy where it should say details, or the reverse. Those two settings explain most of what colleagues see.

After that, the remaining problem is the gaps rather than the blocks, and that is a question of what the calendar records in the first place. Caltimate sets out how a desktop calendar handles that alongside the other Mac options.