Google Calendar meeting reminder: making sure guests get one too

A reminder was set for ten minutes before the meeting. It fired. Nobody else joined. The obvious conclusion is that the reminder failed, so the next attempt adds a second reminder, then an email reminder, then a nudge in chat the night before. None of it helps, because the setting being adjusted was never capable of reaching anyone else in the first place.

This is the single most useful thing to know about a Google Calendar meeting reminder, and it is easy to miss because the setting sits on the event, next to the guest list, as though it applied to the event. It does not. It applies to one person.

A reminder belongs to the person, not to the meeting

Google's own documentation for how reminders work draws the line without hedging. A reminder is an alarm triggered a set number of minutes before an event starts, consisting of when to show it and which delivery method to use. Then comes the part that answers the question: "Reminders are private information, specific to an authenticated user; they're not shared across multiple users."

The structure underneath makes the reason concrete. Default reminders live on the per user view of a calendar rather than on the calendar itself. Google's reminders and notifications reference explains that defaults are handled through the collection holding user specific calendar metadata, and are deliberately not available through the collection holding the global metadata that is shared across all users. The reminder is stored next to the person's name, not next to the meeting.

Two things follow. Setting a reminder on an event you organised changes when your own alarm fires and changes nothing for any guest. And a guest who has their own default reminder on their own calendar will get one whether the organiser set anything or not, at their own chosen interval, which is why guests sometimes report a reminder that the organiser never configured.

The practical translation is blunt. There is no field anywhere in a calendar invite that means "remind the guests fifteen minutes before". What exists instead is a different mechanism, aimed at a different moment.

Notifications are the part that actually leaves the calendar

Alongside reminders, Google Calendar has notifications, and these are the ones that travel. Five types are defined: a new event added to a calendar, a change made by the organiser to an event the person was invited to, a cancellation, an attendee changing their response, and an agenda listing the day's events sent at the start of the day.

Notifications are about changes and about the day ahead. They are not about the fifteen minutes before a meeting. That distinction is the whole reason the search that brings people here rarely has a satisfying answer: the thing being asked for, a reminder pushed onto guests shortly before the call, is not one of the five.

The delivery methods differ too, and this trips people up when they try to work around the limit. Google lists two mechanisms, a pop-up supported on mobile platforms and web clients, and email sent by the server. Reminders can use either. Every one of the five notification types is email only.

	Whose setting controls it	Fires when	Can be a pop-up	Can be an email
Default reminders	Each person, per calendar	A set time before the event	Yes	Yes
Event reminders on one event	Each person, on their own copy	A set time before the event	Yes	Yes
Event creation and change notices	Each person, per calendar	When the organiser edits	No	Yes
Attendee response notices	The organiser, per calendar	When a guest replies	No	Yes
Daily agenda	Each person, per calendar	Start of the day	No	Yes

Read down the first column and the answer becomes structural rather than a matter of finding the right checkbox. Almost every row is controlled by the recipient. The organiser owns exactly one row, and it concerns replies rather than the meeting itself.

What can actually be done for guests

Accepting the limit opens up five levers that do work, in rough order of how much they buy.

Make the invite itself arrive properly

An invite that never landed cannot be reminded about. When an event is created or updated programmatically, notification mail to attendees is not automatic: it goes out when the request sets the update parameter to all attendees, or to external ones only. The equivalent in the interface is the prompt asking whether to notify guests, which is easy to dismiss when making a small edit. A guest who was added during an edit and not notified has a calendar entry and no idea it appeared.

Treat external guests as email only

One group of guests has no calendar entry at all. Google states that for attendees with non-Google email addresses, the notification emails are the only way they can find out about the event, and that the event is not added to their calendars automatically. Nothing at all can be pushed to them later. Whatever is written in the body of that one mail is what they will act on, which makes the time, the date, the zone and the joining link worth writing out in plain text rather than leaving to an attachment.

Move the useful content into the event

A reminder is a knock on the door with no message attached. The event, on the other hand, is what the guest opens. An agenda, the joining link, the document to read and the address all belong there, because that is the surface every guest sees regardless of whose notification settings are switched on.

Let the daily agenda do the work

The one scheduled message in the list that arrives before anything has gone wrong is the agenda, sent at the start of the day with everything on that person's calendar. It is still a per recipient setting, so it cannot be switched on for anyone else. But it is the setting worth naming when asking a team to change one thing, because it covers every meeting at once and it arrives early enough to be acted on. A guest with the agenda enabled has already seen the meeting hours before a fifteen minute pop-up would have appeared.

Ask once, at the calendar level

For a recurring internal meeting where attendance genuinely matters, the intervention that sticks is asking the team to set a default reminder on their own calendar once, rather than asking per meeting. It is a single setting per person that then covers every event they are invited to, and it is the only route by which a guest reliably gets an alarm before a call.

What this looks like to anything automated

Teams that generate invites from a booking form or a script hit the same wall, and the shape of the data explains why. A reminder on an event is expressed as a pair: a switch saying whether to use the calendar's defaults, and, when that switch is off, a list of replacement reminders with a method and a number of minutes each. Reverting to the defaults means flipping the switch back on.

Nothing in that structure is addressed to a person. There is no recipient field on a reminder, because the reminder is already stored inside one person's view of the calendar. A script authenticated as the organiser that writes reminder overrides is writing the organiser's alarms, at scale, and the guests will never see any of them. This is the point where a lot of internal tooling quietly stops matching what its owners believe it does.

What a script can control is whether guests are told. The update call takes a parameter deciding whether notification mail goes to all attendees, to external ones only, or to nobody. Defaulting it to nobody is convenient during testing and is the single most common reason a working integration produces meetings that guests never heard about.

The Mac side: why alerts can be silent by default

Anyone auditing this from a Mac needs to know one more thing, because it explains a lot of apparently missing reminders. Apple's guide states it directly: "By default, events you create don't have alerts associated with them." A fresh Calendar, or a Mac restored from a backup, can be completely silent without anything being broken.

Defaults are set in Calendar, under Settings and then Alerts, and they are per account rather than global. The Account pop-up menu picks which one is being changed, and Apple's guide notes that the settings affect only that account. Separate menus cover ordinary events, all day events and birthdays. A checkbox called "Use these default alerts on only this computer" decides whether the choice travels to other devices, which is the right thing to tick for anyone who wants desk alerts without phone buzzes.

Per event alerts sit on the event's time, under an Alert pop-up menu, and the Custom option opens three delivery choices: a message with sound, an email sent to yourself, or opening a file. One option only appears once a location has been added, called Time to Leave, which fires based on where you are rather than on a fixed interval. That is the more useful alarm for anything you have to travel to, and the way travel time is handled is worth settling at the same sitting, because a fifteen minute warning is not a warning at all when the room is thirty minutes away.

Two limits are worth noting before building a system on this. Exchange events accept only one alert, so stacked alarms will not survive on that account. And any alert set on a Mac is still a local alert. It remains as private as the Google equivalent.

When an alert is set and nothing appears

Four causes account for nearly all of it, and checking them in this order is quicker than re-creating alerts.

macOS decides separately whether Calendar may show notifications at all, in System Settings under Notifications. An alert configured in Calendar and a notification permission refused by macOS produce identical silence.

Individual calendars can be muted. Control-click a calendar in the list, choose Get Info, and there is a checkbox called "Ignore alerts". A muted work calendar looks exactly like a broken alert system, and it survives every other change made in Calendar's settings.

A dismissed notification is gone, and a snoozed one behaves in a specific way. Apple's guide states that choosing Snooze (Automatic) brings the notification back in 9 minutes or at the start of the event, whichever is sooner. Anyone expecting a second reminder closer to the hour after snoozing may get it much earlier than that.

Finally, an alert can be set on the wrong copy. Editing a single instance of a recurring series sets the alert only on that instance, and the rest of the series keeps the calendar default. If the mechanics of building events cleanly are the underlying problem rather than the alerts, the way events get entered is the part that repays attention first.

What to change first

Open Calendar's Alerts settings, pick the account the work meetings live in, and set a default alert there so that no future event depends on remembering. Then stop treating guest reminders as a setting and start treating them as content, by putting the time, the zone and the joining link in the event body where every guest will see it. For a Mac calendar that keeps those details in front of you while the event is being created, Caltimate is built for that.