Google Calendar commute time: the trip that belongs on the week
A meeting ends at ten across town and the next one starts at ten in the office. Both are on the calendar, neither is wrong, and the forty minutes between them exists only in the head of the person who has to make the trip. Anyone looking at that calendar to find a free slot sees a gap at ten and books it.
This is the whole problem with commute time. It is real time, spent, unavailable for anything else, and it is the one part of the working day that most calendars do not record. The fix is not complicated, but there are four genuinely different approaches and they diverge sharply the moment a meeting moves.
Google Calendar has no travel time field
An event in Google Calendar carries a title, a time, guests, a location, a description and attachments. There is no travel time control on the event, and no setting that reads the location and reserves the journey.
The one buffer mechanism Google does document sits somewhere else entirely. Appointment schedules, the booking page feature, have a buffer time setting that inserts a gap either side of each booking. That protects against back to back bookings made by strangers through a link. It does nothing for a meeting created by hand, nothing for an invitation received from a colleague, and nothing at all for the calendar viewed as a whole. Anyone hoping that switching on buffer time will pad the ordinary week is protecting the wrong thing.
The location field does carry weight, though, and it is the input everything else depends on. Entering a real address rather than a room name is the single prerequisite for every automated approach below. A location reading "client office" cannot be routed. A location reading a street address can.
Four ways the journey gets onto the week
| Approach | Updates when the meeting moves | Blocks the time for others | Cost |
|---|---|---|---|
| A buffer event created by hand | No, has to be moved too | Yes, if set to Busy | Free |
| Apple Calendar's Travel Time field | Adjusts with the event time, but not when the location changes | Yes | Free with macOS |
| A service that writes travel events automatically | Yes, recalculates from the location | Yes | Paid after a free trial, priced per user by the vendor |
| A planner app with travel handling built in | Yes | Yes | Morgen lists 15 US dollars a month billed yearly, 30 US dollars billed monthly |
Prices above come from each vendor's own pricing page and change, so they are worth rechecking before a purchase.
The difference between row one and the rest is not convenience, it is failure mode. A hand made buffer event is correct on the day it is created and silently wrong from the first time the meeting behind it is rescheduled. Most calendars full of stale travel blocks were set up carefully once.
What Apple's Travel Time field actually does
The Calendar app on macOS carries a Travel Time control on the event itself, which puts it ahead of Google Calendar on this specific point. It is set by opening the event, clicking the Travel Time pop-up menu, and choosing an option.
Apple attaches one warning to it, and the warning is the important part: "Travel time doesn't update automatically when you change locations." So the field reserves time in front of the event and it moves when the event moves, but it does not recalculate when the destination changes. A recurring visit that switches sites keeps the old journey length.
There is a second limit that is structural rather than documented as a caveat. Travel time is a field in Apple's app. An event synced to a Google account does not gain a travel time property that Google understands, so colleagues looking at the same event in a browser see a meeting with no journey attached to it. For a personal calendar read mostly on a Mac and an iPhone, that is fine. For a shared work calendar where other people check availability, it is not, and the honest answer there is a separate visible event.
The location field in Apple's Calendar is worth setting properly for the same reason. Entering an address, a business name or a type of business such as coffee shop or museum brings up a list to pick from, and pressing Return uses the text verbatim instead. Verbatim text is what breaks routing later.
What the automated services do differently
The category of tool that solves this properly writes real calendar events for the journey, which means the block is visible to everyone who can see the calendar and it blocks availability like any other busy event.
Travel Time, which works with Google Calendar and Outlook, is representative of the approach. A starting address and travel mode are set once, choosing between transit, car, bicycle and walking. When an event with a location is created or updated, the service uses Google Maps to block travel time before and after it. Its stated behaviours cover the cases that break hand made buffers: the travel event moves and recalculates when the meeting is moved or updated, any calendar owned by the account is supported, the travel mode, starting address and return trip can be overridden for a single event, and an extra buffer of a few minutes can be added as a safety margin.
Two of its details are worth singling out. Recurring events get travel time calculated once and shared across all instances, which is faster but carries exactly the weakness Apple warns about, since a series that changes venue keeps one figure. And the smart travel option checks whether travelling directly to the next event is faster than returning to the starting point first, which is the calculation people do in their heads and get wrong.
On price, the Google Workspace Marketplace listing for that add-on records a free trial rather than a free tier, and the figure itself sits on the vendor's own page, so it is worth reading there before committing. A planner app takes the same problem as part of a larger job, and its pricing is published openly: Morgen lists 30 US dollars a month billed monthly, or 15 US dollars a month billed yearly, with a 14 day free trial and full access during it. The arithmetic that matters is the comparison, not the absolute number. A single purpose add-on is the cheaper answer when travel blocking is the only gap on the calendar. A planner at 180 US dollars a year is only worth the difference if daily planning, task handling and booking links are also wanted, because that is what the extra money buys.
The daily commute is a different problem
Two searches land on the same words and want opposite things. One is the trip between two meetings, which is irregular and needs calculating. The other is the journey to and from a workplace, which is the same every office day and needs nothing calculated at all.
For the second, a recurring event is the right answer and automation is overkill. Create one event for the outbound journey and one for the return, set them to repeat on the relevant weekdays, set them to Busy, and stop. Nothing recalculates because nothing changes. The only maintenance is editing the series when the pattern changes, and a repeating event handles that in one edit.
There is a related Google feature that solves the visibility half of this without touching the grid. Working location lets each working day carry a location, entered under Working hours and location in settings or by clicking the location bar beneath a date. Google notes that when a calendar is shared, the recipient can see the working location, and that where a calendar is shared with free or busy visibility, others can view both availability and working location. An administrator may also request that it be set, which is why some organisations show a banner asking for it.
The catch is the same one that applies to working hours. Google restricts these availability features to accounts through a work or school organisation, so on a personal Google account working location is not offered. That leaves the recurring event as the only route, which is no real loss, since a Busy block defends the time and a working location label does not.
Getting this distinction right early avoids paying for automation that solves the wrong half of the question.
Over-blocking is a real cost too
There is a failure mode on the other side, and it shows up about a month after automation is switched on.
Every journey becomes two events, one out and one back. A day with four external meetings gains eight travel blocks, and the week stops being readable. Worse, if those blocks are set to Busy and the calendar is shared, colleagues see a person with no availability at all, and the meetings that actually needed scheduling get pushed into the following week.
Three settings keep this under control, and every serious tool exposes them. Give travel events their own colour so the eye can separate them from work. Mute their notifications, since a reminder for a travel block is noise on top of the reminder for the meeting it belongs to. And decide deliberately whether the return trip is wanted, because for a last meeting of the day ending near home it usually is not.
A useful test after a fortnight: count the travel events in one week and ask how many changed a decision. If the answer is none, the blocks are decoration and the extra buffer minutes are the only part earning their place.
What to look at on a Mac
Commute time is a problem of seeing the whole day at once, which is why it is worse on a phone and worse again in a browser tab behind fourteen others.
Two things make the difference on the desktop. The first is a day view that shows the real shape of the day, including the gaps, at a size where a forty minute hole is visibly different from a two hour one. The second is how quickly a block can be created, because a travel block that takes twenty seconds of clicking never gets created on a busy morning. Typing a line of plain text is the difference between a habit that holds and one that lasts a week, and the travel time section of the guide covers how the journey gets onto the grid without a form.
Scope matters before committing to any Mac calendar. Some read Google, iCloud, Exchange and CalDAV accounts. Others are built around Google Calendar specifically. Since the automated travel services listed above work against Google Calendar and Outlook rather than against a local app, the account that holds the meetings is what decides which combination is available, and the features list states that scope directly.
What to change first
Put a real street address in the location field of every recurring external meeting, because nothing automatic works without it. Then pick one approach and apply it for two weeks: a hand made buffer if external meetings are rare, or a service that writes travel events if they are weekly. Colour them separately and mute their notifications on day one. For the grid those blocks sit in, Caltimate is a Mac option worth a look.
Frequently asked questions
Does Google Calendar have a built-in travel time setting?
No. There is no travel time field on a Google Calendar event and no setting that reads the location and reserves the journey. The only buffer control Google documents belongs to appointment schedules, the booking page feature, and it applies to bookings made through a link rather than to events created by hand.
Will a travel time set in Apple's Calendar be visible to colleagues in Google Calendar?
Not reliably. Travel Time is a field in Apple's Calendar app rather than a property Google Calendar understands, so someone viewing the same event in a browser sees a meeting with no journey attached. For a shared calendar where other people check availability, a separate visible event is the safer choice.
What happens to travel blocks when a meeting is rescheduled?
It depends on the approach. A buffer event created by hand stays where it was put and has to be moved separately. Apple's Travel Time field moves with the event, although Apple notes it does not update automatically when the location changes. Services that write travel events recalculate them when the meeting is created or updated.
Is it worth paying for travel time automation?
It depends on how often external meetings happen. For anyone travelling to meetings weekly, a single purpose add-on tends to pay for itself quickly, because one stale buffer is enough to cause a late arrival and the cost of that lands on a client rather than on the calendar. For someone with an external meeting once a month, a block created by hand is the proportionate answer, and the money is better spent elsewhere.
How are travel blocks kept from making the calendar unreadable?
Give them a distinct colour, mute their notifications, and turn off the return trip where it is not needed, particularly for the last meeting of the day. Recurring events are the other thing to watch, since travel time calculated once and shared across all instances will be wrong for any series that changes venue.