How to account for travel time in Google Calendar so you are not late between meetings

Two meetings sit back to back at 10:00 and 11:00. One is downtown, one is across the river. The calendar shows no conflict, so the invitation gets accepted, and the problem only becomes visible on the morning of, standing at a traffic light. Searching for Google Calendar travel time usually starts here: not with curiosity about a feature, but with a day that already went wrong.

The short answer is that Google Calendar has no travel time field. There is nothing to switch on inside an event that says "add twenty minutes of driving before this." What exists instead is a scattered set of nearby features, a manual habit that works until it does not, and a small market of add-ons that write the travel blocks for you. Knowing which of the three fits the situation matters more than finding a hidden setting, because the hidden setting is not there.

What Google Calendar gives you today

Start with the location field, because it is the piece people mistake for travel time. When an address is typed into an event, Google Calendar stores it and can hand it to Maps. That produces directions on demand. It does not produce a block of time on the grid, and it does not stop someone from booking the half hour before the appointment.

The distinction matters because the calendar's only real job in this situation is to occupy time. A free slot is an invitation. Colleagues with view access, booking pages, and scheduling assistants all read the grid the same way: empty means available. An address in an event body is invisible to every one of them.

There is also no setting at the calendar level that pads events by default. Meeting length defaults can be changed, and a default duration can be set, but a default duration shortens the meeting rather than protecting the gap after it. Shortening a sixty minute slot to fifty gives ten minutes of air, which covers a walk down a corridor and nothing further.

The gap Google Calendar leaves is not a missing checkbox, it is a missing object. Travel is an event with a start, an end, and a location, and nothing in the product creates that object automatically for the events you make yourself.

Buffer time exists, but only for bookings

One place Google does handle padding is appointment schedules, which is the booking page feature. Inside the settings for a bookable schedule, under booked appointment settings, the help documentation lists buffer time as "Add time between appointments on your calendar," alongside a maximum bookings per day limit and guest permissions.

That is genuinely useful, with two limits worth being clear about. The first is scope. Buffer time applies to appointments booked through that page. A meeting someone sends by invitation, or one created by hand, gets nothing. So the person whose day is mostly client bookings gets real protection, and the person whose day is mostly invitations from colleagues gets none.

The second limit is where it can be configured. Google's documentation states that an appointment schedule cannot be created in the Calendar app for Android or iPhone and iPad, and requires a computer with a supported web browser. Some appointment schedule features also depend on an eligible Google Workspace or Google One subscription. For anyone who runs their week from a laptop this is fine, and it is worth knowing before planning around it.

The related setting in the same panel, check calendars for availability, deserves a mention for a different reason. It prevents double booking against other calendars, which is the problem people often confuse with travel time. Availability conflicts and travel conflicts are separate failures. Fixing one leaves the other untouched.

Doing it by hand, and where the habit breaks

The manual method is simple and it works: before accepting an in person meeting, look up the trip in Maps, then create a second event called travel immediately before it, and a third one after if the return matters.

Three things break this habit over time, and they are worth naming because each one has a different fix.

The first is meeting changes. When a 14:00 appointment moves to 15:30, the meeting moves and the travel block does not. Now the calendar shows a phantom trip in the early afternoon and an unprotected gap before the real appointment. The fix is discipline, and discipline scales badly past a few trips a week.

The second is optimism about duration. Maps gives a live estimate for the moment it is asked, not for 17:40 on a Friday. A route that reads twenty two minutes at lunchtime is not a twenty two minute route at rush hour, and the difference between transit and driving can invert depending on the hour.

The third is the free or busy flag. A travel block marked as free disappears from the point of view of anyone reading availability, and from the point of view of a booking page checking for conflicts. The block looks right on screen and protects nothing. Travel events should be marked busy, and if privacy matters, set to private so the address is not exposed while the time is still held.

Add-ons that write the travel blocks for you

Since Google does not create these events, several services do it from the outside by watching the calendar and writing blocks whose duration comes from a routing engine. Two are straightforward to check today.

Travel Time for Google Calendar and Outlook takes a starting address and a travel mode once, then blocks time before and after events that have a location, with durations from Google Maps. Its site lists transit, car, bicycle, and walking as modes, per event overrides for mode, starting address, and return trip, extra buffer time in minutes for a safety margin, a choice of color for the travel events, and an option to mute travel notifications only. Recurring events are calculated once and the result is shared across all instances. Pricing is listed at 5 dollars per month, or 36 dollars per year, after a 14 day trial that does not ask for a card.

Morgen approaches it as a workflow rather than a permanent sync. Its documentation describes an Automated Travel Time workflow that is configured with a target calendar, a departure location, one way or return, a mode from walking, cycling, public transit, or driving, and additional padding up to 30 minutes. Travel time is added for events in the coming week, and the workflows are documented as supported for Google, Outlook, iCloud, and Fastmail calendars.

Approach	What creates the travel block	Covers invitations from others	Stated cost
Location field plus Maps	Nobody. Directions only	No block is created	Included
Buffer time in appointment schedules	Google, for bookings on that page	No	Included, some features need a Workspace or Google One subscription
Manual travel events	The person, by hand	Yes, if they remember	Free, paid in attention
Travel Time for Google Calendar and Outlook	The service, from Google Maps	Yes, for events with a location	5 dollars per month or 36 dollars per year
Morgen Automated Travel Time	A workflow, for the week ahead	Yes, for events with an address	Depends on the plan chosen

The pattern in that table is the useful part. Anything that reads the location field can act on invitations from other people, which is where most of the damage happens. Anything configured per booking page cannot.

Why the calendar app on the Mac changes the problem

Adding a routing service to Google Calendar solves duration. It does not solve the part of the day that is not a meeting.

A schedule with travel in it has a shape. The trip out, the appointment, the trip back, and then the hour of actual work that has to land somewhere. Once travel blocks appear on the grid, the remaining free space is chopped into pieces too small to be useful, and the honest response is to stop accepting a third afternoon meeting rather than to plan a faster route. Seeing that clearly needs a view where every calendar sits on one grid, because a trip scheduled against the work calendar is invisible in the personal one.

This is where a desktop calendar app earns its place over the browser tab. A native Mac calendar keeps the whole week visible without a page load, reads several accounts at once, and lets a travel block be created and dragged in the same gesture as the meeting it belongs to. The specific mechanics of putting logistics onto a grid, including how travel and the work around it get placed, are collected in Travel time, and the broader set of things a desktop calendar can do that a web tab cannot is listed under Features.

Entry speed matters here more than it looks. A travel block that takes four clicks does not get created when the meeting is accepted in a hurry. Reducing that to a typed line is the difference between a habit that holds and one that lapses, which is the subject of Entering events.

What still goes wrong after travel time is on the calendar

Even with blocks in place, a few failures repeat.

Recurring events are the most common. When a weekly visit is calculated once and applied to every instance, a route that is fine in August is wrong in December, and a single moved instance carries the original duration. Check the recurring trips separately from the one off ones.

Mode assumptions come second. A tool configured for driving will happily block twelve minutes for a route that takes forty by train, and the reverse happens in dense cities where driving loses to transit. Where the mode changes by trip, the ability to override a single event is worth more than any other feature in the list.

Changed locations come third. When an in person meeting becomes a video call, the address usually stays in the event. The travel block stays with it, and an hour of the day is held for a trip nobody is taking. Deleting the address is the fix, and it is easy to forget.

Last, time zones. A trip that crosses a zone boundary, or a calendar whose events were created in a different zone, produces travel blocks in the wrong place on the grid. This is worth checking once after any travel week rather than trusting it silently.

What to change first

Start with the events other people create, because that is where the unprotected gaps come from. Put a real address in every in person meeting so that any tool, or a person glancing at the grid, can see there is a trip involved, then decide whether a routing add-on or ten minutes of manual blocking each morning fits the volume of travel in a normal week. If the week is run on a Mac and the pieces need to sit on one grid, Caltimate is built for that view.