How we keep travel blocks live
Published 13 October 2026
A trip DOFOTT writes says how long the road usually takes at that hour. If you have a meeting in Kavacık at 14:00 on a Tuesday, and the drive there from Maslak usually takes 25 minutes on a Tuesday afternoon, the block starts at 13:35. That answers "on a normal day". If the Tuesday of the meeting is not a normal day — an accident on the bridge, rain starting — the block starts at the wrong time, and your phone's reminder comes late with it.
Not any more. About an hour and a half before you leave, and again half an hour before, DOFOTT asks about the road again, for today. When the difference is big enough, the block moves and its title says what to do. This article covers what you see, and then what happens behind it, with the decisions the code makes.
What you see in your calendar
The same meeting, on a day with traffic on the bridge. At 12:05 DOFOTT asks again and Google Maps™ says 41 minutes today. The block moves from 13:35 to 13:19 and its title becomes:
- 🚗 To Kavacık · leave 16 min early
The first line of the description says why: "Traffic: 41 min now, planned 25." When there is a specific cause on the way, one more line follows, such as "There is an accident on the way." Plain heavy traffic gets no sentence; the minutes already say it.
No separate notification comes; the notification is the block itself. Google Calendar™'s reminder is tied to the block's start, so when the block moves earlier, the reminder moves with it. No new app, email or permission.
When the road is clearly lighter than expected it works the other way too: "· leave 10 min later". And on the way home: a trip back starts when the meeting ends and that does not change, so what today's traffic changes is when you arrive. The block stretches at its end and its title says "🚗 To Home · arrive 15 min late".
When it looks
Each trip is checked at most twice. A job on the server runs every ten minutes, collects the driving trips leaving in the next three hours, and sees which check is due for each:
| Check | When | Why then |
|---|---|---|
| First | ~90 min before leaving | Early enough to change your plans |
| Second | ~35 min before leaving | Before your phone's reminder, with traffic at its most accurate |
Because the job runs every ten minutes, "90 minutes" really means between 80 and 90, and "35 minutes" between 25 and 35. The second check is timed from the new departure the first one set: if the block moved 16 minutes earlier, the second check comes 16 minutes earlier too.
Why two, and not every fifteen minutes? Because the number of checks is a question of trust more than cost. A block that shifts every fifteen minutes is a block nobody believes. Two checks cover a moment when you can still decide and a last correction. Once the block has started it is never touched: if you are on the road, your calendar has no need to argue with you.
When it moves: the thresholds
Not every answer from Google moves the block. If the difference stays under a threshold, the block stays where it is:
| Threshold | Also | |
|---|---|---|
| Road slower (leave earlier) | 5 min or more | Nothing else |
| Road lighter (leave later) | 10 min or more | Only while departure is over 45 min away |
The two are unequal on purpose. Being late costs more than arriving early: "leave earlier" comes at five minutes, "you can leave later" only at ten and only while there is still time. A "you can sit a little longer" in the last half hour gives little to someone already getting ready, and costs a lot if it turns out wrong.
There is no percentage threshold. A percentage would announce a two-minute wobble on a ten-minute drive; on an hour's drive five minutes comes before any percentage anyway. A fixed number of minutes is closer to what a person actually notices.
In the example, the second check comes at 12:44 and Google now says 38 minutes. Against the block as it now stands that is 3 minutes lighter: under the threshold. The block stays at 13:19 and the title does not change.
What happens behind it
For the technically curious, the steps the check takes for one trip, in order:
- It reads the block from Google by its id. The database row only says which block to look at; the decision is made on the real block in Google. Without the DOFOTT tag, the right kind (there or back) and the same fingerprint (hash) the database remembers, it is left alone. If the fingerprint has changed, the sync is about to rewrite that block anyway, and the traffic check leaves it to the sync.
- It takes both ends of the trip from the block itself. The database keeps no addresses. The start of the trip is in the block's private tag (from), the destination in the block's location. Your home and work addresses have coordinates in your settings, so those are sent as coordinates rather than text: the point asked about today is the same point the plan was made with.
- It asks Google's Routes API with today's traffic. The departure sent is the block's start (or a minute from now). That answer is never cached: the seven-day cache used when planning is for "a normal day", and this question is about today.
- It works out the target. On the way there: the meeting's start, minus today's duration, minus your buffer if you set one, rounded down to the minute. On the way back: the block's start plus today's duration plus the buffer, rounded up. The rounding always goes your way.
- It checks the threshold and patches the block if needed. Only the block's start (or, on the way back, its end), its title and the first paragraph of its description change. The paragraph the previous check wrote is replaced, not stacked.
- It saves where things stand. The block's new departure, which fingerprint was looked at, and which check has been done. If the meeting changes later, the sync rewrites the block with the usual duration, the fingerprint changes and the count starts over: the next check corrects it again for today's traffic.
The minutes in the title are measured from where the block was first planned, not from the previous check. If the second check says "19 min" instead of "16 min", it means leave 19 minutes earlier than planned. There is one reference point for the reader: what the block said when it was first written.
Weekly meetings
The trips for a repeating meeting are one repeating block series. In the week traffic is bad, the check moves only that week's block, as an exception to the series in Google Calendar™; the series and the other weeks stay as they are. The sync does not count that exception as a drift and does not undo it.
There is a catch: the database row stands for the whole series and does not know which day this week's trip falls on. So for an account with a series, the check lists DOFOTT's blocks for the next three hours from Google, and keeps each week's own state (its planned times, how many times it was checked) in a separate table. The thresholds, the wording and the two checks are the same as for one-off meetings.
"There is an accident on the way": where the reason comes from
The duration comes from Google, the reason from TomTom. The reason is asked only when a block is about to tell you to leave earlier. Three things go to TomTom: the starting address and the meeting's location as you wrote them, and the departure time. Not your name, your email address, the event's title or an identifier for your account. TomTom finds the address itself and draws the route itself.
There is a line in the other direction too: none of Google's map data goes to TomTom — neither Google's route nor its coordinates. Google Maps™ Platform's terms forbid it, and we would not want it anyway. The two answers meet only on our server, side by side in one sentence of the description. TomTom's duration is not used to check Google's either; TomTom only answers "why".
The reason never stops a block from moving. If TomTom does not answer, the block still moves, just without the reason line. When a reason is written, "Traffic data © TomTom" goes under it. All of this is on the privacy page as well.
When something goes wrong
The principle: if the traffic check fails, the block stays where it was planned. No error deletes a block or moves it to a wrong time.
- If Google has no route, nothing changes for that trip. If the Routes API cannot be reached at all, the job stops for everyone on that round and tries again ten minutes later.
- If the block was deleted between being read and being written, the patch falls through; the sync notices, and a block you deleted never comes back.
- If the sync is working on your calendar at that moment, the traffic check waits; the two never run on one account at the same time, and it tries again on the next round.
What it does not do
- Driving only. Transit, walking and cycling trips stay as planned.
- It does not move your meeting. DOFOTT only touches the trips it wrote, never your own events.
- It does not hide a clash. If the road between two back-to-back meetings gets longer and runs into the first meeting, the block is not clipped; the calendar shows the clash and the title says "leave early". Whether there is time to go home in between is not decided again with live traffic either.
- It does not report its own work. The title and description say what the road is doing, not what DOFOTT did. You will not see "last checked 14:05" or "updated 3 times".
Live traffic is on every plan; it is not tied to a paid plan and does not change what is counted: what counts is still meetings with a place, not traffic checks. The drawn version of all this is on the How DOFOTT works page.
Google Calendar™ and Google Maps™ are trademarks of Google LLC.