Google Calendar email reminders to others: what guests can be sent

A client keeps missing the call. The fix seems obvious: set a reminder on the event so the client gets an email an hour before. So the organizer opens the event, sets the reminder to email, saves, and nothing arrives on the other side. The reminder fires, but it fires for the person who set it.

This is the single most common misunderstanding about Google Calendar. Reminders and notifications look like one feature in the interface, and they behave like two completely different things. Knowing which is which decides whether the reminder ever leaves the organizer's own inbox.

Reminders belong to the person who set them

Google Calendar treats a reminder as private data attached to one account. The documentation for the Calendar API states it plainly.

Reminders are private information, specific to an authenticated user; they're not shared across multiple users.

That one sentence rules out the approach most people try first. Changing an event's reminder from pop-up to email does not create an email for the guest list. It changes when and how the account that owns that copy of the event gets alerted. Every guest holds a separate copy of the event on a separate calendar, and each copy carries its own reminder settings.

The same is true one level up. Default reminders are set per calendar, so a calendar can be told to alert ten minutes before every event it holds. Those defaults apply to that calendar only, and they are stored as account-specific metadata rather than as part of the event itself. Two people looking at the same meeting can be alerted at completely different times, and neither can see what the other chose.

There are limits worth knowing when the reminder does belong to the right account. An event can carry up to five reminders that override the calendar default, and the lead time can be set from zero minutes up to 40,320 minutes, which is four weeks. Anything earlier than four weeks has to be handled by placing a separate preparation event on the calendar and putting the reminder on that.

Notifications are the part that does leave the account

The feature that actually sends mail to other people is the notification system, and it is triggered by activity on the event rather than by the clock. Google Calendar sends notifications for five kinds of activity: a new event added to a calendar, a change made by the organizer to an event the recipient was invited to, a cancellation of such an event, an attendee changing a response on an event the recipient created, and the daily agenda that lists everything on the calendar for that day.

One detail shapes every workaround built on top of this. Notifications are delivered by email only. Reminders can be sent as a pop-up or as email, but every notification type in that list is email or nothing. There is no setting that moves a guest response notification to the desktop, and there is no setting that sends a timed notification the way a reminder is timed.

Behaviour	Reminder	Notification
Triggered by	the clock, before the event starts	activity on the event
Controlled by	each account, for its own copy	each account, for its own calendars
Reaches guests	no	yes, when the event is created or changed
Delivery	pop-up or email	email only

Read that table and the design intent becomes clear. Google Calendar expects the organizer to communicate by changing the event, and it expects each attendee to decide personally how and when to be alerted.

What a guest actually receives

When an event with attendees is created, the event appears on the primary calendar of each attendee with the same event ID, and an invitation email goes out if updates are set to be sent. Through the API this is the sendUpdates parameter, set to all for everyone or to externalOnly for guests outside the organization. In the interface, the equivalent is the prompt that appears on save asking whether to send invitations.

Guests on a Google account can accept or decline from that mail, and they can adjust their own copy afterwards, including adding a reminder to it. That last point is the honest answer to most requests for guest reminders: the guest can create exactly the reminder being asked for, and only the guest can.

Guests on an address that is not a Google account are in a different position, and the documentation is direct about it.

For attendees with non-Google email addresses, these notification emails are the only way they can find out about the event; the event is not added to their calendars automatically.

For those guests, the invitation email is not a courtesy copy. It is the entire record of the meeting. Anything they need at the moment of the meeting has to be inside that mail, because there is no event on their side to open later.

Routes that do put a message in front of a guest

Once reminders are set aside, four routes remain, and each has a clear cost.

The first is the invitation itself. Since the description travels with the event and can contain HTML, the joining link, the address, the agenda and the phone number can all sit inside the body a guest receives. This costs nothing and works for guests on any mail provider.

The second is a deliberate change to the event. Because notifications fire on changes, editing an event and choosing to send updates produces fresh mail in every guest's inbox. Used once the day before a meeting, to add the final agenda or confirm a room, it functions as a reminder without pretending to be one. Used often, it trains guests to ignore the mail, so it is worth spending on the one change that matters.

The third is a message sent outside the calendar entirely. A short mail written by hand, a calendar-linked automation that watches for events starting soon and sends mail on a schedule, or a booking tool that owns its own reminder sequence. The trade-off is that the reminder is no longer tied to the event record, so a rescheduled meeting can leave a stale reminder in the queue.

The fourth applies to recurring internal work rather than to clients. If a team subscribes to a shared calendar, each member can set a default reminder on that calendar once and stop thinking about it. The organizer does not control the timing, but the habit only has to be set up a single time per person.

Recurring meetings make the gap obvious

A weekly call is where the difference between reminders and notifications stops being academic. The organizer sets it up once, and from then on the calendar sends nothing at all. No notification fires, because nothing about the event has changed. Every guest who shows up is relying on a reminder they configured themselves, or on their own habit of reading the day ahead.

That is usually fine for an internal team and unreliable for anyone outside it. The people who miss recurring calls are rarely the ones who never agreed to them. They are the ones whose copy of the event was created weeks earlier, with a default reminder of ten minutes that they set for a different kind of work, on a calendar they no longer look at every morning.

Two adjustments help without asking anything of the guest. The first is to keep the series short and renew it, so a fresh invitation goes out every few months and the event is re-read rather than inherited. The second is to attach the joining link and the current agenda to the series description and update it when it changes, which produces a change notification and pulls the meeting back into view.

For recurring internal work, a shared calendar is a cleaner answer than a guest list. Each person subscribing to that calendar can set one default reminder for everything it holds, and the timing is then a decision each person makes once. The organizer gives up control over that timing, which is the trade being made in every part of this system.

Where the request usually comes from

Almost every search for guest reminders starts with a meeting that was missed, and the reminder is a guess at the cause. It is worth checking the guess. A client who missed a call at 10:00 while sitting at a desk was not short of alerts. Something else went wrong: the invitation landed in a spam folder, the time zone on the event was not the one the guest reads, the meeting was moved and the update never went out, or the joining link was buried under three paragraphs of pleasantries.

Those causes have different fixes, and none of them is a reminder. A spam problem is fixed by sending the invitation from a known address. A time zone problem is fixed on the event, because the event carries its own time zone and each guest sees it converted. A stale event is fixed by sending the update rather than editing quietly. A buried link is fixed by putting the link on the first line of the description.

The reminder question is also worth asking in the other direction. If the organizer needs a reminder in order to send something to a guest, that reminder lives on the organizer's own calendar, where it works exactly as intended. A task titled "send the agenda" placed the afternoon before the meeting, with an email reminder attached, is a two-minute setup that solves the human half of the problem.

Keeping the details where the guest will read them

The practical conclusion from all of this is that the description field carries more weight in Google Calendar than most people give it. It is the one part of an event that reaches every guest, on every mail provider, without depending on anyone's notification settings. An event with a bare title and an empty body forces every guest to ask a question, and those questions arrive as mail too.

This is where the speed of creating events starts to matter. Typing a full description into a browser form is slow enough that most events end up with a title and nothing else. Some Mac calendar apps let events be created by speaking or typing a plain sentence, which lowers the cost of including the address and the joining link at the moment the event is made rather than later. The mechanics of that are covered in Entering events, and the wider set of behaviours in Features.

Travel is the other half. A reminder cannot make a guest leave earlier, but an event that already accounts for the journey does not need the rescue alert in the first place. That approach is described in Travel time.

What to change first

Stop trying to push a reminder onto a guest and put the meeting's details inside the event description instead, so the invitation mail is self-contained. Then place one reminder on the organizer's own calendar the day before, to send any final update while the change notification still has time to arrive. If events are being created too quickly for the description to get written, that is a tooling problem rather than a discipline problem, and Caltimate exists for that part.