Googleカレンダーの通知: what it does and where it breaks down

Reminders either stop arriving or arrive constantly, and both situations send people to the same settings page. The page is not where the answer usually is. Google Calendar notifications are not one feature. They are several mechanisms with different delivery routes, different owners, and different failure points, all filed under one word. Separating them turns a vague complaint into a short list of things to check, and the list is shorter than it looks.

Three routes, and one of them splits in two

Google's own documentation lists three destinations for a notification: a phone, a web browser, and email. The browser destination then divides again.

A desktop notification appears outside the browser window, as a system popup, and only while Calendar is open. An alert appears inside the Google Calendar page itself. Email lands in an inbox. A phone with the Calendar app installed adds push on top of all of this.

The split matters because each route fails for a different reason. A desktop notification that never appears points at browser permission or at operating system settings. An alert that never appears points at the Calendar tab not being open. An email that never appears points at filtering rather than at calendar configuration. Treating these as one symptom is what turns a five minute fix into an afternoon.

The routes also differ in what they leave behind. A desktop notification disappears if nobody is watching, though macOS can hold it in Notification Center. An alert is waiting whenever the Calendar page is opened. Email stays until it is deleted and can be searched months later. Choosing a primary route is really a choice between being interrupted and keeping a record.

One route runs even for people who never open Calendar at all. If someone is invited to an event, they receive email when that event is created, updated, or deleted. That is why turning every notification off still leaves a trickle in the inbox.

A reminder stores two values and nothing else

The Google Calendar API describes an event's reminders as either the calendar default or a list of overrides. Each override carries exactly two things: a delivery method, which is popup or email, and a number of minutes before the event starts.

The bounds are fixed. An event accepts up to five override reminders, and each one takes a value between 0 and 40,320 minutes. That ceiling is four weeks expressed in minutes, so a reminder set a month before a deadline is within range.

This shape is not specific to Google. RFC 5545, the specification behind the calendar file format, defines an alarm as a component attached to an event, and requires exactly two properties on it: what kind of alarm it is, which can be audio, a display message, or email, and the trigger that decides when it fires. Every calendar product that interoperates works from the same two values.

The consequence is worth stating plainly. A reminder has no knowledge of what surrounds the event. It does not know whether travel is required to get there, whether the previous meeting tends to run long, or whether another calendar already has something in that slot. A ten minute warning that arrives too late to act on is not a misconfiguration. It is the expected behavior of a component that was only ever told a number.

The settings belong to one person

Shared calendars generate a recurring misunderstanding about who controls what.

Your notification settings are personal and apply only to your account, whether you use a personal, work, or school account. Your calendar-level settings determine your notifications for new events, unless you customize them for a specific event. Source: support.google.com

Adding a reminder to an event does nothing for the guests invited to it. Their own settings decide what they see. The reverse also holds, so nobody sharing a calendar can change these settings on someone else's behalf. Any attempt to make other people remember something by adding reminders will fail silently, which means important information belongs in the event description or in an email where it persists.

Work and school accounts carry one more quiet behavior. When an administrator changes an event on a user's calendar, the user gets no notification about it. An event that appears to have rewritten itself, with nothing in the inbox to explain it, is usually this.

Calendar defaults, and why all day events sit in their own box

What a newly created event inherits comes from the calendar it lands on. In settings, each calendar the account owns shows two separate blocks, one labeled event notifications and one labeled all day event notifications. They are configured independently.

Keeping them identical is the most common cause of alert volume. Notification count then scales with how many events exist rather than with how many need a decision.

The all day block exists separately because all day events have no start time. Setting zero minutes on one produces a notification at the moment the day begins, which is too late to change a deadline, a renewal, or a travel day. Moving only the all day default to the previous evening changes what those reminders are worth without changing how many arrive.

These default blocks appear only for calendars the account owns. A calendar shared by a colleague, or a feed subscribed from an external URL, has no default block at all, so reminders have to be attached event by event. Most reports of shared calendars never producing notifications trace back to this structural detail rather than to a broken setting.

The chain a notification has to survive

Google's troubleshooting list names three conditions, and the third catches most people.

Link in the chain	What has to be true	Where it is set
Calendar	Notifications are turned on for that calendar	Google Calendar settings
Browser tab	Google Calendar is still open in the browser	The browser itself
Site permission	calendar.google.com is allowed to show notifications	Browser site settings
Operating system	The browser is allowed to post notifications	macOS Notifications settings
Focus	Interruptions from that app are permitted	macOS Focus settings

Browser notifications stop the moment the Calendar tab is closed. Site permission is separate again: in Chrome it lives under privacy and security, then site settings, then notifications, where calendar.google.com has to be added to the allowed list. That permission is stored per browser and per machine, so an office Mac that shows reminders and a home Mac that shows none is entirely normal.

Underneath sits macOS, which decides per application whether notifications are allowed, whether they appear as a banner that clears itself or an alert that stays put, whether they collect in Notification Center, and whether a sound plays. A Focus adds one more gate on top.

Phone and computer settings are shared rather than separate. Google notes that setting a one hour reminder on a phone also produces a popup on the computer an hour ahead. That cuts both ways: a reminder deleted on one device is gone on the other. The exception is device level muting on Android, where silencing the Calendar app on the handset leaves computer and email notifications intact.

Email reminders and popup reminders are not the same mechanism

The two delivery methods available on a reminder look like a preference, but they run in different places, and that difference decides which one survives a bad setup.

An email reminder is produced on Google's side and handed to a mail system. Nothing on the local machine has to be running, no permission has to be granted, and no operating system setting can suppress it. It arrives whether the Mac is asleep, the browser is closed, or the account is being read from a borrowed computer.

A popup reminder is the opposite. The server knows when it should fire, but something local has to be present to display it. That local thing is a browser tab, or an app, and everything described in the previous section applies to it.

This is the practical test for narrowing down a complaint. Set one event with both an email reminder and a popup reminder at the same offset. If the email arrives and the popup does not, the reminder itself is configured correctly and the problem is somewhere between the browser and macOS. If neither arrives, the reminder was never set where it was assumed to be, which usually means it went onto a different calendar or a different account.

It also explains a common workaround. People who read calendars on several machines they do not control tend to drift toward email reminders, not because email is better, but because it is the only route with no local dependencies.

When the same event fires three times

Some complaints about volume are really complaints about duplication. An account read simultaneously by the browser, by a phone app, and by a desktop calendar app can produce three notifications for one event. Every piece is behaving correctly, so trimming reminder counts only ever half fixes it.

Google's guidance for this is to turn notifications off in the other calendar app, through the phone's own settings screen. The same situation occurs on a Mac when a Google account has been added to a desktop calendar application, because that application raises its own alarms alongside the browser.

The order that works is to pick one primary route first and silence the rest completely. Reducing a little in each place instead tends to remove the reminder that mattered and leaves no way to work out which setting did it.

The filters most accounts never turn on

Three settings reduce noise without deleting reminders.

The first is response based filtering. A checkbox in notification settings limits notifications to events the account has answered yes or maybe to. In an organization full of broad invitations, this alone changes the daily count substantially.

The second is snooze, available after desktop notifications are enabled, with a configurable delay. Two conditions apply: snooze works only in Chrome, and when an event carries several reminder times, the snooze option appears only on the last one.

The third is category level email control. Under other notifications for a calendar, categories such as changed events and event responses can each be set to email or to nothing. This is a separate system from event reminders, so inbox volume can be cut without touching what pops up before a meeting.

What to change first

Spend one week counting two numbers: reminders received, and reminders that changed what happened next. A wide gap is a defaults problem, and it is solved in the per calendar and all day blocks described above, with Guide covering the order to work through and Entering events covering how events should be recorded so the defaults do the right thing. If instead the misses come from not knowing which calendar held the event, reminders were never the mechanism at fault, and the question becomes whether everything can live in one window. Compared with other calendars sets out the differences between the desktop options without a sales angle, and Caltimate lists what a native Mac calendar handles that a browser tab cannot.