FlowKit

Detecting and resolving calendar double-booking conflicts with n8n

Published 29 August 2026 · 6 min read

A client books a visit through Cal.com. The same day, a sales rep blocks the same slot by hand in Google Calendar for a different appointment, without noticing the slot is already taken elsewhere. Both events sit quietly on the shared calendar until someone notices — often the same day, in front of the two people who show up at the same place at the same time. This isn't a Google Calendar bug: it's the mechanical result of having several entry points (a booking tool, manual entry, a CRM sync) each writing to the same calendar without consulting one another. n8n can fill exactly that gap, by watching the calendars involved and flagging — or resolving — overlaps before they turn into a visible problem for the client.

Why conflicts happen despite modern tools

A booking tool like Cal.com or Calendly does check availability — but only within its own record, at the moment of booking. A foundational study on shared calendar systems, Palen (1999), Social, Individual and Technological Issues for Groupware Calendar Systems, published at CHI, already shows that the core difficulty of shared calendars isn't technical but organizational: several people and several tools modify the same time-bound resource without full visibility into one another, which mechanically produces double bookings as the number of entry points grows. Twenty-five years later, the problem is identical — only the tools changed: Cal.com, a CRM, and manual entry now play the role that paper calendars and separate front desks played when the study was written.

The cost of this kind of conflict isn't just the awkwardness of a double appointment. Czerwinski, Horvitz, and Wilhite (2004), A Diary Study of Task Switching and Interruptions, published at CHI, documents how much an improvised, last-minute schedule fix — rescheduling, notifying people, reassigning a resource — fragments the rest of the workday well beyond the time strictly needed to resolve the conflict itself. Catching the overlap before it lands in front of a client avoids that cascade entirely.

What Google Calendar doesn't do on its own

n8n's Google Calendar node (see our full Google Calendar node guide) faithfully executes whatever it's asked — create, list, update an event — but never compares two events against each other on its own initiative. Three blind spots come up over and over:

  • The gap between tools. An appointment booked on Cal.com or Calendly (see our Cal.com and Calendly guides) writes an event to Google Calendar via sync or webhook — but a manual entry made in parallel, before that sync propagates, entirely bypasses the booking tool's own availability check.
  • Resources shared across several calendars. A meeting room booked from a person's own calendar and from the room's resource calendar can end up double-booked if nobody cross-checks both agendas.
  • A poorly set "available" status. An event created with transparency set to transparent ("available") rather than opaque ("busy") — imported from an external calendar, or an "FYI" event — doesn't show up as a blocker during a free-slot check, even though it represents a real commitment for the person involved.

Building the conflict detector in n8n

The principle: regularly query the calendars involved over a rolling window, compare every pair of events that share a resource or a person, and fire an alert as soon as an overlap is found.

1. Triggering

Two complementary triggers, not mutually exclusive:

  • A Schedule Trigger every 10 to 15 minutes, re-reading every relevant calendar over the next 7 to 14 days — the safety net that catches everything, including conflicts created by a source that fires no event at all (a CSV import, a late manual entry).
  • A Google Calendar Trigger on Event Created and Event Updated, to check the new event immediately rather than waiting for the next polling pass — useful when an appointment is confirmed live to the client and you want to know right away whether it overlaps something.

2. Fetching the events to compare

A Google Calendar node in Get Many mode, iterated once per calendar involved (each rep's agenda, each room's resource calendar), filtered to the same time window. When several calendars need to be walked, a Loop Over Items node runs the fetch for each one, then a Merge node folds everything into a single list before comparison.

3. Detecting overlaps

This is the workflow's core, in a Code node. For every pair of events sharing a resource (same room, same person, same client ID), compare the [start, end] intervals:

const { DateTime } = require('luxon');

function overlaps(a, b) {
  const startA = DateTime.fromISO(a.start).toUTC();
  const endA = DateTime.fromISO(a.end).toUTC();
  const startB = DateTime.fromISO(b.start).toUTC();
  const endB = DateTime.fromISO(b.end).toUTC();
  return startA < endB && startB < endA;
}

Our Luxon guide for dates and times in n8n covers this time-zone handling in detail — a real point of attention: comparing timestamps without first normalizing them to UTC is the most common source of false positives (two events in different time zones wrongly flagged) or false negatives around daylight-saving transitions. Only compare events whose transparency is opaque (busy): an event marked "available" shouldn't trigger an alert.

4. Routing by severity

An IF node splits the cases:

  • Full or partial overlap on a single resource (same room, same person) → immediate alert, this is a real conflict.
  • Overlap only on a buffer window (a 5-10 minute gap between two appointments rather than a true overlap) → a simple warning, often tolerable depending on the business.

5. Resolve, not just report

A Slack alert listing the two conflicting events is the bare minimum, but two options go further:

  • Suggest a reschedule. An AI Agent queries the affected calendar's free slots over the following days and proposes two or three alternatives directly in the alert message, instead of leaving the person to reopen Google Calendar and search themselves.
  • Never auto-reschedule without human sign-off. Moving a client appointment without confirmation is exactly the kind of high-impact action that deserves an approval step — the same pattern described in our guide to human approval with Wait + Slack: the workflow proposes, a person approves with one click, and only then does the Google Calendar node run the Update operation.

Concrete use cases

  • Real estate viewings. An agency scheduling property visits (see our guide on AI-assisted real estate visit reports) easily ends up with the same agent's calendar booked both from the website and from a phone call entered by hand: a check before confirmation prevents sending two clients to the same property at the same time.
  • Shared meeting rooms. An SMB managing several rooms through Google Workspace resource calendars can apply the same detector by cross-checking each room's calendar against the invited attendees' calendars.
  • Multi-channel service providers. A consultant who accepts bookings via Calendly, email, and phone benefits from an after-the-fact check — the upstream availability check built into any single booking tool never covers the channels it can't see.

Common pitfalls

  • Comparing raw date strings instead of time objects normalized to UTC — two events that look identical in local time but sit in different time zones aren't necessarily in conflict, and the reverse is also true.
  • Ignoring the transparency field and alerting on "FYI" events that don't actually block any resource.
  • Watching only one calendar when the conflict actually plays out across two separate calendars (a personal agenda and a room's resource calendar, for instance) — the comparison needs to cover every resource that's genuinely shared.
  • Rescheduling without telling anyone: an automatic appointment move with no human approval and no notification to the client is the kind of fix that creates a second problem worse than the first.

Going further

The alerting infrastructure used here — detection, Slack notification, incident logging — is the same logic as the daily digest workflow in the Inbox AI Pack (€79), which already centralizes an inbox's priorities and urgent items into a Slack or Telegram channel. If that Slack notification stack already exists for your emails, wiring this calendar conflict detector into it takes just one more webhook — not a new integration built from scratch.

FAQ

Frequently asked questions

Does n8n's Google Calendar node natively detect duplicate bookings?

No. The Google Calendar node runs whatever operation it's asked to (create, list, update) without checking on its own whether an event overlaps another one. Conflict detection has to be built explicitly into the workflow, by comparing the time ranges of the events retrieved.

Why does a conflict happen even when everyone uses Google Calendar?

The most common case is having several entry points: a client books through Cal.com or Calendly, a sales rep enters an appointment by hand in Google Calendar, a third channel (CRM, form) creates an event on its own. Each tool checks its own availability but is blind to bookings created elsewhere — the conflict only surfaces once both events coexist on the same calendar.

Do I need to compare calendars every minute to catch every conflict?

Neither necessary nor realistic with a polling trigger. A check every 10 to 15 minutes is enough for most businesses (appointments, meeting rooms), paired with an immediate check on the Google Calendar Trigger's Event Created event to validate the new booking as soon as it's created, ahead of the next polling pass.

How should time zones be handled when comparing time slots?

Always convert timestamps to UTC before comparing them, using Luxon in a Code node. Comparing raw date strings without normalizing them into a common time zone is the most common cause of false positives (two events in different time zones wrongly flagged as conflicting) or false negatives around daylight-saving transitions.

Bundle FlowKit Complet

€269