Automatically add travel time to Google Calendar: the trip counted

A calendar that shows a 9:00 meeting across town and a 10:00 meeting back at the desk is not describing a day anyone can live. The trip between them is real, it takes twenty minutes or fifty depending on the hour, and nothing on the screen accounts for it. Google Calendar happily accepts both events. It will also happily let a third one land at 9:45.

The location field looks like it should solve this. Type an address, and Calendar shows a map preview and a link to directions. It does not turn that address into time. There is no setting in Google Calendar that reads the location of the next event, measures the trip from the previous one, and blocks the gap. Every page that ranks for this query is really answering a different question: which layer to add on top, and what that layer has to get right before it stops being annoying.

What Google Calendar does with a location, and what it leaves alone

Worth being precise about the gap, because it explains why the workarounds look the way they do.

Google Calendar's help pages cover a lot of scheduling machinery. You can set working hours and a working location on a work or school account so that people booking with you see when you are unavailable. You can create appointment schedules. You can attach labels to events and track them in Time Insights, also on a work or school account. You can change the view span and event density so more of the day fits on screen.

None of those touch travel. The event location stays a string with a map attached. Directions open in Maps when clicked. The duration of the journey is never written back onto the calendar, so nothing stops a later invitation from filling the gap, and nothing warns you when the gap was never big enough in the first place.

That is the whole problem, and it is worth stating plainly because it sets the bar. Any solution has to write actual events, or actual busy time, into the calendar. Advice that ends at "add the address so you can check the directions" has not solved anything. You already had Maps.

The four ways people actually do this

There are four shapes, and they differ less in what they achieve than in what they cost and what breaks.

Manual blocks. Create an event called Travel before and after the trip, look up the duration once, and drag it into place. It works, it is free, and it falls apart the moment a meeting moves. Most people who search for the automatic version have already spent a month doing this.

A third party service connected to the calendar. You grant a service access to your Google or Microsoft account, set a home address and a default travel mode once, and it writes travel events whenever you create or change an event with a location. Travel Time is the most visible of these. Its own pages describe a 14 day trial with no card, then 5 USD per month or 36 USD per year, and state that it uses Google Maps to block the time before and after events with a location.

A script you own. Google Apps Script can read calendar events, call a directions service, and create the travel event. Installable triggers can run it on a schedule or on a calendar change, and they run under the account of whoever created them. This costs nothing and bends to any rule you want. It is also code you now maintain, and the quota and failure behaviour become yours.

A calendar app that does it in the app. Some desktop calendars calculate the journey themselves and place the block, rather than adding a robot to the account. Apple's own Calendar user guide for Mac includes a page on adding a location and travel time to an event, so this is not exotic. It is a normal feature of a calendar client.

Approach	Recurring cost	Writes to the calendar	Breaks when
Manual travel events	None	You do	Any meeting moves
Connected service	5 USD monthly or 36 USD yearly for Travel Time	The service, via your account	Access is revoked, or the origin guess is wrong
Apps Script	None	Your script, as you	The script errors and nobody is watching
Calendar app feature	Depends on the app's licence	The app, locally	Only on the machine with the app

The fourth column is the one to read twice. Every approach works on a calm week. What separates them is the week where three meetings move.

The five things "automatic" has to handle

A travel blocker that only handles the simple case creates more work than it saves, because now there are wrong events on the calendar as well as missing ones. Judge any option against these five.

It has to follow the event. Move a meeting to the afternoon and the travel block must move and be recalculated, not sit where it was. Travel Time states this explicitly on its site, which is the right thing to advertise, because a block that does not follow is worse than no block.

It has to know where you are coming from. The trip to a 14:00 appointment is not the trip from home if the 13:00 meeting was somewhere else. Systems that only store one starting address will be wrong on exactly the days that matter, the days with more than one location. Look for a per event override of the origin, or logic that chains from the previous event.

It has to handle the return leg, and know when not to. Some days end at the last appointment. Some days end back at the desk. A tool that always adds a return trip will double the phantom busy time, and one that never adds it will make you late for the evening. Travel Time's smart travel option checks whether going straight to the next event is faster than returning to the starting point first, which is the shape of the right answer.

It has to respect the travel mode, per trip. Transit and driving diverge by more than a few minutes in a city, and the mode is a property of the trip, not of the person. A global setting of Car is wrong on the day the car is in the garage.

It has to leave a margin. Door to door duration from a maps service is the moving time. It is not the time to park, find the floor, or wait for a lift. A fixed buffer of five or ten minutes, added on top, is what turns a technically correct estimate into a schedule that survives contact with a building. Travel Time exposes this as extra buffer time. A calendar app that measures the trip should be checked for the same control.

Where the travel block should live

Two decisions get made badly and then quietly annoy people for months.

The first is which calendar the travel events go on. Putting them on the main work calendar means colleagues checking availability see the trips, which is usually the point. Putting them on a separate calendar means they can be hidden in one click when the week looks cluttered, at the cost of no longer blocking time for people who only see the main calendar. Pick based on whether the goal is to protect the time from other people or to see it yourself.

The second is notifications. A travel event that fires a notification twenty minutes before it starts is duplicating the notification from the meeting itself, and two alerts for one obligation trains you to ignore both. Travel Time offers a mute option for travel events specifically, leaving normal event notifications alone. The better pattern is a single alert at the time you need to leave, tied to the actual origin, rather than a generic reminder attached to a block.

That second pattern is what a calendar running natively on the machine can do more cleanly, because it knows where the previous event was and can recompute the departure time as the day shifts. The travel time and time to leave behaviour is worth comparing directly against a connected service on this point alone, since the connected service is writing events into Google and then has to notify through Google's own alert system.

Colour, and why the travel block should not look like a meeting

Small thing, large effect. If travel events use the same colour as meetings, the week reads as solid work, and the eye cannot find the parts of the day that are actually negotiable. If they use a distinct pale colour, a glance separates commitments from the logistics around them.

Google Calendar exposes eleven named event colours. The names in the interface are Lavender, Sage, Grape, Flamingo, Banana, Tangerine, Peacock, Graphite, Blueberry, Basil and Tomato, which the Apps Script EventColor reference maps to its own identifiers for anyone automating this. Graphite and Lavender are the usual picks for travel, because they recede. Travel Time lets you choose the colour its events use, and any script you write can set it directly.

The reason to bother: once travel is visually distinct, the honest shape of the week becomes visible. Most people who do this discover they have fewer usable hours than they thought, which is uncomfortable and also the entire value of the exercise.

Recurring events, and the case nobody tests

A weekly standup at the same address is easy. A weekly client visit where the traffic pattern differs between a Tuesday and a Friday is not, and this is where implementations diverge quietly.

Travel Time states that for recurring events the travel time is calculated once and shared across all instances. That is a reasonable engineering decision and it is also a real limitation: the number reflects one snapshot, not each occurrence. For a fifteen minute walk it does not matter. For a drive across a city at two different times of day it can be wrong by half.

If a recurring trip matters, check the behaviour before trusting it, and consider leaving that one series with a manual block sized to the worst case. An automation you understand the edges of is more useful than one you assume is smarter than it is.

Which calendars the automation can reach

One constraint gets missed in the setup and then shows up as a mystery. Travel Time states that any calendar you own is supported. Ownership is the operative word. An event sitting on a colleague's calendar that you were invited to, or on a team calendar somebody else administers, is not necessarily a calendar the automation can write a travel block beside.

That matters because the trips that catch people out are usually externally imposed. A client books a site visit, the invitation lands, and the acceptance goes onto your calendar as a guest. Whether the tool treats that as an event on your own calendar or as a foreign object determines whether the trip gets blocked at all, and it is worth testing with a real invitation rather than a test event you created yourself.

The same question applies to an account with several Google calendars attached. If personal and work calendars are both connected, decide whether travel should be written for both, and whether a personal errand should be blocking work availability. Most people want travel on the work calendar and nothing automatic on the personal one, and most tools default to something else. Check it during the trial while you are still paying nothing.

What to change first

Pick one week and add travel blocks by hand, with a real margin, for every event that has an address. That single week tells you how many hours the trips actually consume and whether the problem is worth automating at all. If it is, decide between a connected service and a calendar that measures the trip locally on the two questions above: whether it chains the origin from the previous event, and whether it tells you when to leave rather than when the block starts. Caltimate is built around the second answer, and the FAQ covers what it needs access to.