
GoHighLevel Google Calendar Not Syncing: Causes and Fixes
Why a GoHighLevel calendar connected to Google Calendar stops syncing or shows conflicting availability, the most common causes, and how to fix each one, including choosing one-way vs two-way sync.
Key takeaways
- The most common root cause of a broken Google Calendar sync is an expired or revoked OAuth token, not a bug in GoHighLevel itself: the fix is disconnecting and reconnecting the calendar under the correct Google account.
- One-way sync only pulls Google Calendar busy/free time into GoHighLevel to block availability; it does not push GoHighLevel bookings back into Google Calendar, which surprises teams expecting bookings to appear on their personal calendar automatically.
- Two-way sync pushes GoHighLevel appointments into Google Calendar and pulls Google Calendar events back in, but it only works cleanly when a staff member's calendar isn't also being managed by a second scheduling tool at the same time.
- Duplicate or 'ghost' events almost always trace back to a calendar being connected under two different GoHighLevel users, or to a sync mode change that wasn't followed by a manual sync refresh.
- Timezone mismatches between a sub-account's default timezone and a Google Calendar's timezone setting create real double-bookings, not just display glitches, so both need to match before trusting the calendar for live bookings.
- A single team member should connect to a single GoHighLevel calendar with a single sync mode. Layering multiple GoHighLevel calendars onto one Google account is the setup pattern most likely to produce conflicting availability.
A GoHighLevel calendar that stops syncing with Google Calendar almost always traces back to one of a small number of causes: an expired OAuth token, a sync mode that doesn’t match how the calendar is actually being used, a timezone mismatch, or a Google Calendar connected to more than one place at once. None of these require rebuilding the calendar from scratch. Each has a specific, checkable fix, and the sync mode itself, one-way versus two-way, is a setup decision worth getting right the first time rather than troubleshooting after double-bookings start reaching real customers.
This guide walks through each cause in the order worth checking, then covers how to choose between one-way and two-way sync for a given team setup.
If you’re setting up GoHighLevel more broadly and calendars are just one piece of the build, the complete agency setup guide covers sub-accounts, snapshots and workflow configuration around it.
Start by checking the OAuth connection
The single most common reason a Google Calendar sync stops working is that the OAuth token connecting GoHighLevel to the Google account has expired or been revoked. This isn’t a GoHighLevel-specific quirk; it’s how OAuth-based integrations generally behave once a token is invalidated on the Google side.
A few things trigger this. A Google account password change can invalidate existing app authorizations. A Google Workspace administrator can revoke third-party app access as part of a security review, which silently breaks the GoHighLevel connection without any notification inside GoHighLevel itself. And tokens can occasionally expire from age even without any deliberate action, particularly if the connection hasn’t been re-authenticated in a long time.
The fix is straightforward: open the calendar’s settings inside GoHighLevel, disconnect the existing Google Calendar connection, and reconnect it, making sure to authenticate with the correct Google account when the OAuth prompt appears. GoHighLevel’s own calendar integration documentation covers the reconnection steps in more detail. Reconnecting generates a fresh token and, in most cases, resolves the sync failure immediately without any other changes needed.
Permission scope changes block the sync silently
Google Calendar’s OAuth consent screen asks for specific permission scopes, typically read/write access to calendar events. If a user only grants read-only access during the initial connection, or if Google updates its permission model and the existing grant no longer covers what GoHighLevel needs to write events, the sync can degrade without an obvious error message. Events might read into GoHighLevel but never write back out, which looks identical to a one-way sync even if two-way was intended.
The way to check this is to disconnect the calendar and reconnect it, paying close attention to the permissions screen that Google presents during authentication. Google’s calendar API exposes distinct scopes for this exact reason: a read-only scope that only lets an app see events, and a full-access scope that lets it create and modify them. If the consent screen only lists something like “see events on all your calendars” and not “make changes to events,” the connection was granted read-only, and two-way sync has no way to write bookings back regardless of what mode is selected inside GoHighLevel. Grant full calendar access during reconnection if two-way sync is the goal. If a Google Workspace admin has locked down which scopes third-party apps can request, that’s worth flagging to IT directly, since no amount of reconnecting inside GoHighLevel will fix a scope restriction set at the admin console level.
One-way vs two-way sync: what each mode actually does
This is the setup decision that causes the most confusion, because “sync” sounds like it should mean full, symmetrical updates in both directions, and in one-way mode it doesn’t.
One-way sync pulls events from Google Calendar into GoHighLevel to block availability. If a staff member has a personal appointment on their Google Calendar, GoHighLevel sees that time as busy and won’t offer it as a bookable slot. What one-way sync does not do is push GoHighLevel bookings back to Google Calendar. A new appointment booked through a GoHighLevel calendar page won’t show up on the connected Google Calendar at all under this mode.
Two-way sync does both directions. Google Calendar events block GoHighLevel availability, and GoHighLevel bookings get written to the connected Google Calendar as new events. This is the mode most teams actually expect when they hear “sync,” and it’s the right choice whenever a staff member needs to see their GoHighLevel bookings on the same calendar they use for everything else, without manually copying appointments over.

The practical way to choose: if the Google Calendar’s only job is blocking out a person’s existing commitments (a shared front-desk calendar, or a provider who books almost everything through GoHighLevel already), one-way sync is simpler and has fewer failure points. If staff manage their day primarily from Google Calendar and need GoHighLevel bookings to land there automatically, two-way sync is the correct mode, and it’s worth confirming it’s actually selected rather than assumed, since GoHighLevel defaults can vary by calendar type.
Timezone mismatches cause real double-bookings
A sub-account has a default timezone setting, and a connected Google Calendar has its own timezone setting. When these don’t match, the practical result isn’t just a display quirk, it’s a genuine scheduling conflict: a slot that looks open in GoHighLevel’s timezone can actually overlap an existing commitment in the Google Calendar’s timezone.
This shows up most often after a business relocates, adds a remote team member in a different timezone, or when a sub-account’s timezone was set incorrectly during initial setup and never corrected. The fix is to check both settings directly, the sub-account’s timezone under company or calendar settings inside GoHighLevel, and the timezone attached to the connected Google Calendar, and set both to the timezone the business and staff member actually operate in. Google’s own Calendar timezone settings documentation covers how to check and change the timezone on the Google side.
Duplicate and ghost events
Duplicate events, appointments that appear twice, or “ghost” events that show as busy time with no corresponding real appointment, usually come from one of two setup issues rather than a sync bug.
The first is a Google Calendar connected to more than one GoHighLevel user or calendar simultaneously. If two GoHighLevel calendars both have write access to the same Google Calendar, each can create its own copy of an event, or one can create an event the other doesn’t recognize as already existing. The fix is auditing every GoHighLevel calendar in the sub-account and confirming each connected Google Calendar is linked to exactly one GoHighLevel calendar.
The second is a sync mode change that wasn’t followed by a manual resync. Switching a calendar from one-way to two-way (or the reverse) changes how future events sync, but old events created under the previous mode can persist as orphaned entries. Triggering a manual sync or, if the calendar allows it, briefly disconnecting and reconnecting after a mode change clears most of these leftover entries.
Multiple calendar connections on one user
A related but distinct problem: a single staff member with more than one GoHighLevel calendar, each independently connected to the same Google account. This is common when a business creates a new calendar for a new service line and connects it to an existing team member’s Google account without checking whether an older calendar is still connected too.
The result is conflicting availability, since GoHighLevel is now managing bookings against the same underlying calendar from two separate configurations that may have different sync modes, buffer times or availability windows. The fix is consolidating to one active GoHighLevel calendar per staff member wherever possible, or, if multiple calendars are genuinely needed for different service types, making sure only one of them has write access to the connected Google Calendar under two-way sync, with the others set to one-way or disconnected from that same Google account.
Choosing sync settings for your setup
For a solo provider whose Google Calendar already holds their real schedule, two-way sync usually makes sense, since it keeps that one calendar as the single source of truth in both directions.
For a multi-staff sales or service team, two-way sync per staff member is typically the right default, so each rep sees GoHighLevel bookings on their own calendar automatically, without a manual step. The setup risk to watch for here is exactly the “multiple connections” issue above: each rep should have one calendar, one sync mode, one Google account.
For a shared front-desk or dispatch calendar that exists purely to block out known unavailability (holidays, existing commitments, equipment downtime), one-way sync is often simpler and reduces the number of things that can desync, since nothing is being written back to Google Calendar for anyone else to interpret.
When to disconnect and start fresh versus troubleshoot in place
Most of the issues above (an expired token, a scope problem, a timezone mismatch, a leftover duplicate) are fixed by disconnecting and reconnecting the specific calendar affected, or by correcting a single setting. That’s a five-minute fix, not a rebuild.
A full disconnect-and-rebuild is worth it when a calendar has accumulated multiple overlapping connections over time, when nobody is confident which sync mode is actually active, or when the calendar has been handed off between staff members without a clean reconfiguration each time. In that situation, disconnecting entirely, confirming the correct sync mode for the calendar’s actual use case, and reconnecting once cleanly is faster than chasing down every leftover duplicate individually.
Where to start when sync issues keep coming back
Most sync failures come down to an expired OAuth token, a sync mode mismatched to how the calendar is actually used, a timezone that doesn’t match between GoHighLevel and Google Calendar, or a Google Calendar connected in more than one place. Check the connection status and sync mode first before assuming anything deeper is broken, and keep the one-to-one rule in mind: one staff member, one Google Calendar, one GoHighLevel calendar, one sync mode. If calendar sync issues keep resurfacing across multiple sub-accounts, that’s usually a sign the underlying setup pattern needs correcting rather than another one-off reconnect, and it’s the kind of foundational fix covered under GoHighLevel implementation services.