Googleカレンダーの通知: how to decide what you need

Most people approaching Google Calendar notification settings start with the question of how many minutes before an event the alert should fire. Ten minutes is too late to leave a desk. Thirty minutes is early enough to be forgotten by the time the meeting starts. The number gets nudged back and forth for months and never settles, which suggests the number was never the decision.

Google Calendar stores notification settings in three separate places, and each place applies to a different set of events. Change one and the others keep behaving as they did. Choosing a lead time before choosing which layer to change is why the setting appears to have no effect, and why recurring events booked last year keep firing on rules nobody remembers writing.

The three layers a setting can live in

The same word covers three storage locations:

• Account level settings, covering new events, changed events, canceled events, event responses, and a daily agenda
• Calendar level defaults, split into event notifications and all day event notifications
• Per event overrides attached to a single entry

Google's help page is explicit about how the bottom two relate:

Unless you customize notifications for specific events, notifications for new events are determined by your calendar level settings. Source: support.google.com

The load bearing phrase is new events. A calendar level default does not reach backwards. Changing it and then watching an existing meeting fire the old way is not a bug, it is the documented behaviour. The reverse is also true: an override attached to one event outlives whatever reason it was created for. A one day lead time added during a tense project sits on a weekly recurring meeting forever, firing every Monday about a Tuesday call that nobody needs a day of warning for.

The order of decisions runs top to bottom. Decide what arrives by email at the account level, then decide the calendar defaults, then override only the exceptions. Done in that order, every event created from then on carries the right notification without a decision. Done bottom up, the same judgement gets made repeatedly at event creation time, and settings drift apart because the judgement is never made the same way twice.

Timed events and all day events are separate choices

The calendar level panel lists event notifications and all day event notifications as two different rows. Filling them in with the same instinct produces a calendar that works for meetings and misbehaves for everything else.

All day events have no start time, so a lead time measured in minutes has nothing to measure from. Deadlines, anniversaries, travel days, days off: these are specified as a time on the previous day instead. The question that decides the value is whether there is still time to act when the alert arrives. A document deadline is worth knowing about on the morning before. Knowing about it at 10pm the night before changes nothing.

All day events also arrive in clusters. Holiday calendars and anniversary entries are stored as all day events, so leaving the default on produces several unrelated alerts on the same morning a few times a month. Because the volume is hard to predict, a conservative default with deliberate exceptions holds up better than a generous default with manual cleanup.

Lead time follows the action, not the importance

There is one question that settles a lead time. What does the reader start doing the moment the alert appears? Once the action is named, the time it takes is the answer.

Action the alert triggers	What sets the lead time	Fallback if unclear
Leave for somewhere	The actual travel time	Measured duration plus a margin
Open a document or a screen	Preparation time	5 to 10 minutes
Reach someone before the meeting	Their response time	30 to 60 minutes
Nothing at all	No alert is needed	Remove the notification, keep the event

There is a second question worth asking alongside it: what happens if the alert is missed entirely? An alert for something with a hard external consequence, a flight or a client call, earns a longer lead time than the action alone would justify, because the cost of being late is not symmetric with the cost of being early. An alert for an internal check in that can be rescheduled by message earns less than the action alone suggests. Importance on its own is a poor guide, since almost everything on a calendar feels important while it is being scheduled. The asymmetry between arriving early and arriving late is the part that actually varies.

The last row is where most notification fatigue comes from. Events attended passively, meetings hosted by someone else, tentative blocks with no confirmed time: alerts on those lower the proportion of notifications that lead to any action. Once that proportion drops, the alerts that do matter get dismissed with the same reflex as the ones that do not. Removing action free notifications does more for reliability than tuning the timing of the rest.

For anything involving travel, the lead time is the wrong instrument anyway. An alert can tell someone they will not make it. It cannot stop the impossible pair from being booked in the first place. Treating travel as time that occupies the calendar is covered in Travel time, and it removes the class of problem rather than announcing it.

The account level settings carry information no reminder can

Focusing only on pre event alerts hides a panel that matters more. At the account level, five categories can each be set to email or to nothing:

• New events
• Changed events
• Canceled events
• Event responses
• Daily agenda

The test for each is whether a pre event reminder could carry the same information. For changes and cancellations it plainly cannot. A meeting cancelled two hours ahead produces no alert at its start time, because the event is gone. The email is the only channel that reports it. Setting that category to nothing buys quiet at the cost of never learning that something moved.

Event responses are the category most likely to flood an inbox, since hosting a meeting with a dozen invitees produces a dozen acceptance emails. Turning the whole category off also removes declines and time change replies, which are the messages worth reading. A mail filter that archives acceptances while leaving declines visible keeps the signal and drops the volume.

The daily agenda works differently: one message each morning listing that day's events. For someone trying to reduce per event alerts, it consolidates the information into a single interruption. The limitation is that it is composed in the morning, so events added during the day do not appear in it. Work where the day fills in as it goes is a poor fit.

Deciding what to do about invitations

Accounts that receive many invitations get alerts for events the owner never replied to. Google Calendar offers a setting that limits notifications to events the owner answered yes or maybe to.

Whether that setting helps depends entirely on local habit rather than on the setting itself. In a workplace where invitations get answered, restricting alerts to answered events is sound. In a workplace where people attend without replying, the same setting silences meetings they fully intend to join. The way to decide is to count: look at one week of events and check what share of them carry a response. The number decides it, and it is different in different teams.

The phone holds a separate set of the same decisions

Everything above describes the settings reached from a browser. The Google Calendar apps for Android and for iPhone carry their own notification settings, documented on separate pages from the desktop instructions, and nothing configured in a browser reaches them.

That matters for the arithmetic rather than for the principle. A person who carefully sets a calendar default to one alert per event, then counts the interruptions a meeting actually produces, will usually find more than one, because the phone applied its own default to the same event. The settings screen on the desktop reports exactly what was configured there, so the discrepancy reads as a sync fault rather than as two independent sets of rules.

The decision worth making deliberately is which device is the one that interrupts. A phone is the copy that still works when the laptop is closed, which argues for keeping alerts there and thinning them on the desktop. A desk based day argues the other way, since an alert on a phone lying face down in a bag accomplishes nothing. What does not work is leaving both at their defaults and treating the combined result as a single setting, because tuning one of them then appears to have no effect on the total.

Whichever device is chosen, the count is the check. Take one real meeting, note every interruption it produces across every device and the inbox, and compare that to the number intended. Where the two disagree, the extra ones are coming from a layer that was never opened.

Notification settings exist only for calendars you own

The last piece of the decision is not a setting at all. Notification defaults appear for calendars the account owns. Subscribed calendars, calendars shared by someone else, and imported feeds have no panel to configure, which means no default can be applied to them.

That turns a settings question into a placement question. To be reliably alerted about something sitting on a shared calendar, there are two routes: receive it as an invitation so it lands on an owned calendar, or create a matching event on an owned calendar. No amount of tuning reaches the other case.

It also means that splitting work and personal life across calendars split the notification defaults at the same moment. Configuring one and leaving the other untouched is common, and the symptom is specific: events on the quiet calendar are the only ones ever missed.

Putting the conditions in one order

What is being decided	Where it is decided	The test
How changes and cancellations reach you	Account level	Could a pre event alert carry this?
Default for timed events	Calendar level	Is there an action the alert starts?
Default for all day events	Calendar level	Is there time to act the day before?
Exceptions	The individual event	Measured travel or preparation time
Where the event lives	Choice of calendar	Is this calendar owned?

Decided in that order, the top two rows are set once and rarely revisited. Only the bottom two change with any regularity.

One factor sits outside the settings entirely. A notification can only fire for an event that exists, so anything agreed verbally and never typed is beyond the reach of every option above. Lowering the cost of entry does more for coverage than any lead time, which is what Entering events covers. How different Mac calendars handle alerts, sync scope, and whether alerts survive a closed browser tab is laid out in Compared with other calendars.

What to change first

Open the account level settings and confirm that changed events and canceled events are still set to email. If either reads as nothing, no amount of care at the other layers will surface a meeting that moved. After that, set the calendar defaults for timed and all day events separately, and leave per event overrides for genuine exceptions. Where entry itself is the bottleneck rather than alerting, a native Mac calendar closes that gap in a way a browser tab cannot.