Googleカレンダーの共有 not working: what to check, in order

A calendar was shared and something is wrong on the other side. The settings screen looks correct, the share was granted twice to be sure, and the recipient still says it is not working. That loop is common, and it happens because the settings screen is almost never where the problem is.

A share has three segments: the grant on the sending side, the delivery path, and the way the receiving application handles what arrives. The symptom looks the same from the sender's chair regardless of which segment failed. Sorting the symptom first, before opening any settings, is what turns a long afternoon into a five minute fix.

Place the symptom before touching anything

The first action is not a setting change. It is a single question to the recipient, and there are only three possible answers.

Is the calendar missing from the list entirely. Is it in the list but showing nothing useful. Is it visible but behaving wrongly.

Each answer points at a different segment. Missing from the list means the delivery path failed, and no amount of adjusting permission levels will help. In the list but empty means the grant or the organizational ceiling is the cause. Visible but unusable means the level granted does not match what the person was asked to do.

Getting a screenshot is faster than getting a description. Asked in words, every one of these compresses down to "it is not working", and the distinction that would have resolved it in one step disappears. A single image of the recipient's sidebar and week view answers the question without any further exchange.

The calendar is missing from their list

If the name never appeared on the other side, the grant probably landed and was never activated. Check in this order:

• Did the invitation email arrive at all, including the spam folder
• Did they click the link in it. Until that link is opened, the calendar does not appear in their list
• Which account were they signed into when they clicked. Anyone signed into several Google accounts in the same browser can open an invitation under the wrong one
• Is the address on the sharing list the address they actually use. Aliases and forwarded addresses are a frequent mismatch

The third item catches more cases than the rest combined. People running a work account and a personal account in one browser click the link under whichever session happens to be active, and the invitation is consumed against an account that was never granted anything. Signing out completely and opening the link again under the granted address settles it.

A mismatched address is visible from the sending side. The sharing list still shows whatever was typed, so reading the addresses aloud against what the recipient confirms is the cheapest check available.

Group addresses need a separate check. Sharing to a group carries access to anyone who joins later, which is the point of doing it, but some group configurations do not accept mail from outside the group, and the invitation never arrives. If an individual address works and the group address does not, the group's own delivery settings are where to look.

It is in their list but nothing useful shows

The calendar appears, the week looks empty. The first suspect is the level that was granted, because the lowest level does not transmit any event content.

The person you share with can only see when your calendar is busy. Source: support.google.com

At that level the recipient sees unlabeled blocks. This matters for diagnosis, because "empty" and "blocks with no titles" are wildly different problems and both get reported as blank. Ask specifically whether any blocks are present.

If blocks are present and the level has already been raised without effect, the next suspect is the organizational ceiling. Google Workspace administrators cap external sharing, and the personal settings screen still offers levels above the cap without any warning. Externally, the recipient gets whatever the cap allows, and from the sender's chair everything looks correctly configured.

If not even a block appears, the likely cause is a calendar mix-up. The settings page is entered by selecting a calendar on the left, and a share applied to the wrong calendar is invisible as an error. Confirm that the calendar holding the events is the same one holding the sharing list.

It is visible but will not move

When the recipient reports seeing events but being unable to change them, there are two candidate causes, and they are distinguishable by a single count.

The lowest writing level, "Make changes (see private events as free/busy)", allows editing ordinary events but leaves anything marked private opaque and immovable. The recipient sees a block, cannot read it, and cannot shift it. This is the mechanism behind most delegated scheduling failures, where an assistant moves everything they can find and leaves a few blocks untouched.

The count settles it. If only specific events resist, private event settings are the cause, and the fix is either changing those events or raising the level. If nothing at all can be moved, the granted level never reached a writing level in the first place.

External recipients have a third possibility. One of the administrator options is to share all information while outsiders cannot change calendars. Under that setting, no external person can edit anything, at any level the sender selects.

There is a fourth case that looks identical and is not a permission problem at all. If the event in question was created on a calendar the recipient does not have access to, and they are only attending it as a guest, their ability to change it is governed by the guest permissions on that specific event rather than by anything on the sharing list. An event where "Modify event" was left unticked will not move no matter how generously the underlying calendar was shared. When exactly one event misbehaves and it happens to be a meeting they were invited to, check the event's guest settings before touching the calendar.

Changes arrive late

The setting is right, the recipient is looking at an older version. This is normally not a fault at all, just a difference in how the calendar is being delivered.

Address based sharing puts the recipient in front of the same data, so changes land immediately. A subscription through an iCal address works by the recipient's application fetching on its own schedule, so the view stays stale until the next fetch. Apple's Calendar on Mac exposes an auto-refresh setting on subscribed calendars, and whatever interval is selected there governs the delay. The publisher cannot influence it.

Administrator changes are slower again. Google's guidance is that changes can take up to 24 hours, though usually less. Checking the recipient's screen right after an admin adjustment and filing it as broken starts an investigation into a problem that has not had time to exist yet. Note the time of the request and re-check the following day.

Before any of that, rule out a stale view on the receiving end. Switching to a different month and back, restarting the application, and forcing a manual refresh of the subscription cover most of these, and all three take seconds.

To distinguish late from never, create one marker event with the current time in its title and watch how long it takes to appear. If ten minutes pass with no sign of it, the problem is not latency and the settings are worth opening.

The same event appears twice

Duplicates are not a sharing failure. They mean one calendar is reaching one person through two paths at once. The usual combinations:

• Address based sharing plus a subscription to the same calendar's iCal address
• A guest invitation on the event, plus sharing of the calendar that holds it
• The same account added twice in the recipient's application
• A previously exported file imported by hand on top of a live feed

To identify which, have the recipient click one of the duplicates and check which calendar it belongs to. Different calendar names mean two delivery paths. The same name twice means the account is doubled in their client.

When removing one, keep the writable path and drop the read only subscription. Reversing that leaves the recipient able to see the calendar and unable to act on it, which usually produces the next support question within a day.

Times are off, or all day events land on the wrong date

Events appearing a few hours out point at time zones, and there are three places to look: the time zone set on the event itself, the calendar's default time zone, and the recipient's application. The most common finding is an event created for an overseas meeting whose per-event time zone was never set back.

All day events sliding to the previous or following day are a different problem with a similar appearance. All day events carry no time, so the importing application decides how to anchor them, and the anchoring can shift the date. This shows up most often on calendars consumed through an iCal subscription, and adjusting settings on the sending side frequently changes nothing. Where the exact date matters, creating the event with real start and end times rather than as an all day event is the reliable path.

Once it is fixed, keep it fixed

Most recurring sharing problems come from having more than one delivery path to the same person. Duplicates come from it. Half-stale views come from it. Diagnosis time scales with the number of paths in play, so collapsing to one is the single highest value change after a fix.

Recording what was granted matters almost as much. A note of who holds what level, on which calendar, turns the next report into a lookup instead of an investigation. Without it, every repeat of the same symptom costs the same full diagnosis, and the symptoms do repeat, because turnover keeps adding new recipients to arrangements nobody documented.

Separating internal and external audiences onto different calendars removes a whole family of reports on its own. Organizational ceilings only apply outward, so a calendar that never leaves the organization never produces the invisible cap that generates the hardest symptom on this list.

On the receiving side, shared and owned calendars stack up in one view and the writable ones stop being obvious, which is its own source of friction. How a Mac client handles several accounts at once, and how it marks read only subscriptions, is covered under Features. Where the approaches differ in practice is laid out in Compared with other calendars.

What to change first

Ask the recipient which of the three states they are in, and get a screenshot rather than a description. That one answer removes two thirds of the possible causes before any setting is opened. After that, cut every duplicate delivery path down to one, since that is what makes the next report diagnosable at all, and the remaining cost is how long it takes to enter events, which is the side Caltimate is built around.