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

When Google Calendar alerts stop showing up, the usual response is to open the settings screen, find nothing wrong, restart the browser, find nothing wrong, and then recreate the event. That sequence rarely reaches the cause, because it starts in the middle.

An alert passes through four gates before it reaches a screen. The event has to carry a notification. The calendar has to have desktop notifications switched on. The browser has to permit that site to send notifications. The operating system has to permit that browser to display them. A failure at any gate produces one identical symptom, and the settings screen looks correct in all four cases. Testing them in a fixed order, from the innermost outward, is what makes the result readable.

First split: never arrived, or arrived unseen

Before the ordered checks, separate two symptoms that have causes in completely different places.

• The alert never appeared at all
• The alert appeared and vanished before anyone looked

The second is not a fault. macOS offers two per app styles for notifications: one that disappears after a while, and one that stays until dismissed. With the first style selected, an alert delivered while nobody was at the desk is delivered correctly and disappears unseen. Opening Notification Center settles this in seconds. If past alerts are sitting there, delivery is working, and the thing to change is the macOS notification style rather than anything inside Google Calendar.

Only when Notification Center holds nothing does the ordered checklist below apply.

Gate 1: does the event itself carry a notification

Start at the innermost point. Open the specific event that failed and look at whether any notification rows are attached to it.

Missing rows are more common than expected. Calendar level defaults apply to events created after the default was set, so anything created earlier has nothing attached. Events arriving as invitations do not necessarily pick up local defaults. Events written by an external system, such as a booking tool or a meeting platform pushing entries into the calendar, frequently arrive with no notification at all.

A fault found here ends the investigation, because it affects one event and nothing else. Rows present but silent means the cause is further out, and the next gate applies.

Gate 2: is the calendar set to send desktop notifications

The second gate is the account wide notification setting, found in the general section of Google Calendar settings. If the notification type there reads as none, no event level configuration will produce anything on screen.

Google's own troubleshooting page begins at this point:

Click the settings icon, then Settings. In the General section in the left sidebar, click Notification settings. Click the Notification dropdown and confirm that Desktop notifications are on. Source: support.google.com

The detail that catches people is that this setting belongs to an account, not to a browser. Someone signed into a work account and a personal account has two independent copies of it, and configuring one leaves the other untouched. A symptom where events from one account fire and events from the other stay silent is almost always this, and it survives every browser restart because the browser is not involved.

Gate 3: is the browser permitting that site

Past this point the settings are outside Google Calendar entirely. The browser keeps a list of sites allowed to send notifications, and calendar.google.com has to be on it. In Chrome the list sits under Privacy and security, then Site Settings, then Notifications.

Absence from that list happens without anyone consciously refusing anything. The permission prompt was dismissed without being read. A new browser profile was created. The calendar is open in a private window. A managed device ships with notification permissions restricted by policy. None of these record a refusal that is visible later. The site is simply not on the list.

Sound is governed separately. Browsers keep a second list of sites allowed to play audio, and an alert that appears silently usually means the site is on the notification list but not the sound list. Because the two permissions are independent, fixing one leaves the other half of the symptom in place.

Gate 4: is the operating system permitting that browser

The outermost gate is macOS. In System Settings, under Notifications, each application has its own entry, and the browser has to be allowed there. Permission granted inside the browser does not survive a denial at this level.

The same panel controls how alerts behave once they appear. Temporary alerts disappear after a while, persistent alerts remain until dismissed. Anyone whose real complaint is missing meeting starts while away from the desk wants the persistent style, because it converts a missed moment into something still waiting on return.

Focus modes deserve separate attention, because they produce the least reproducible version of this problem. A Focus on a Mac syncs with other devices signed into the same Apple Account, so one turned on from a phone silences the Mac as well. Focus modes that activate on a schedule or by location produce alerts that fail only within a certain window, and the failure never reproduces during the afternoon spent investigating it. Where the symptom is intermittent, checking whether a Focus was active at the time of the missed alert comes before anything else.

When the alert fires, but at the wrong moment

A separate class of complaint gets filed under the same heading: the alert arrives, and it arrives an hour off. None of the four gates explain that, because all four are working correctly. The alert is firing exactly when it was told to.

Two mismatches produce this. The first is an event created while the account was set to one time zone and read while the device is in another, which is routine for anyone who travels or who accepted an invitation from a colleague in a different country. The event holds a time zone of its own, and the alert is calculated from that, not from the clock on the wall. The second is a recurring series created before a daylight saving change, where the series keeps its original offset and the local clock has moved underneath it.

The check is to open the event and look at the time zone recorded on it rather than at the time displayed in the grid. Where they differ, the alert is honouring the recorded one. This is worth separating early, because an hour of offset investigated as a delivery failure leads through all four gates and finds nothing wrong at any of them.

When the phone and the Mac disagree

A frequent version of this problem is not that alerts stopped, but that they stopped in one place. The phone still buzzes and the Mac stays silent, or the reverse.

The Google Calendar mobile apps keep their own notification settings, documented separately for Android and for iPhone, and they are not governed by anything configured in a browser. Two independent sets of rules operate on the same events, which means a symptom present on only one device rules out gates one and two immediately: an event with no notification attached, or a calendar switched off entirely, would be silent everywhere.

That narrows a one sided failure to the device specific layers. On the silent Mac, that means the browser's site permission, the system permission for the browser, and any active Focus. On a silent phone, it means that app's own notification settings and the equivalent system permission there.

It is also worth confirming that both devices are looking at the same account. An alert arriving on a phone signed into a personal account and not on a Mac signed into a work account is not a fault at all. It is two accounts behaving correctly, and no amount of permission checking on either device will change it.

Reading the symptom to skip ahead

Working outward in order is reliable, but a distinctive symptom narrows the search.

Symptom	Most likely gate
One specific event stays silent	Gate 1, no notification on the event
Only one account's events are silent	Gate 2, per account setting
Everything stopped on a particular day	Gate 3, site permission or a new profile
Alerts appear but make no sound	Gate 3, separate sound permission
Silent only at certain hours	Gate 4, a scheduled Focus
Alerts are sitting in Notification Center	Gate 4, temporary alert style
Silent on days the tab was closed	Not a setting at all

That last row is a different category of problem. Desktop notifications originating from a web page depend on the calendar being open in the browser. Close the tab, restart the browser, or work in a different profile, and nothing fires even though every setting is untouched. Because the settings screen reports no change, this reads as an unreliable, intermittent fault. A problem that keeps returning after being fixed is usually this one, and the thing to examine is the delivery route rather than the configuration.

Confirming a fix without waiting for the next meeting

The slowest part of this work is not finding the cause. It is failing to confirm each fix, because alerts only fire when an event is due.

Creating a disposable test event removes the wait. Make a short event starting three minutes out and attach two notifications, one at zero minutes and one at two minutes. The second one exists to separate a bad lead time from a dead route: if neither fires, the route is blocked, and if only one fires, the timing was the issue. Delete it afterwards.

Run that test after each gate, not after all of them. Fixing four things and then testing once produces a working calendar and no knowledge of which change mattered, which means the entire sequence gets repeated the next time the symptom returns.

Why the same fault keeps coming back

Looking at the four gates together, only the first two belong to Google Calendar. The other two belong to the browser and the operating system. An account where this problem recurs is therefore not an account with bad calendar settings. It is one where the alert depends on conditions the calendar does not control.

Two directions reduce the recurrence. One is removing the browser from the path, so that alerts come from the operating system directly and are no longer tied to whether a tab is open or which profile is in use. The other is depending on alerts less. Travel booked as time on the calendar stops the impossible pair from being scheduled rather than announcing it late, which is the reasoning in Travel time. Nothing fires at all for an event that was agreed verbally and never typed, so reducing the cost of entry matters as much as fixing delivery, and that is covered in Entering events. How different Mac calendars handle alerts, sync scope, and whether alerts survive a closed tab is set out in Compared with other calendars.

What to check first

Open Notification Center. If missed alerts are sitting there, the problem is the macOS alert style and nothing in the calendar needs touching. If it is empty, start at the event and work outward, testing after each gate with a three minute throwaway event. For a path that does not depend on a browser tab staying open, a native Mac calendar removes gate three from the chain entirely.