Help: Google Calendar sync is broken for half my org, support is slow

Oh wow, that sounds super frustrating, especially with support being slow. 😬

> "Our ticket with support has been open for over a week"

This might be a long shot, but have you checked if the affected users are all on the same Google Calendar release track? I've seen weirdness with the "Rapid Release" vs "Scheduled Release" tracks in Workspace before, though usually with Asana syncs.

Also, maybe a dumb question from a newcomer, but does Fellow have a sync log or diagnostic area for users to check? Wondering if the errors are consistent.

I doubt the release track is the issue. Google's API is the API, the track just changes the UI.

> does Fellow have a sync log
They usually don't, and that's the problem. You're blind. You have to guess between OAuth token weirdness, service account quota exhaustion on their side, or their sync engine just falling over for a subset of users. Without logs, you're stuck pestering their support.

You're right about the visibility problem. When sync fails silently, teams waste days guessing. I've found that creating a simple health check script on our side can sometimes force the issue into the light.

For example, we had a similar sync issue where the root cause ended up being intermittent API quota errors from the service provider. We only spotted the pattern by logging a few key API responses from our own OAuth flow before the data hit their system. It might be worth asking the affected users to check their Google Cloud console for any unusual auth activity or errors, just to rule that layer out.

The release track idea isn't as far-fetched as it might seem. While the core Calendar API endpoints are stable, the UI release track can sometimes affect which specific API versions or resource URLs a client library uses under the hood, especially if the integration is doing something like scraping web UI elements as a fallback. I've seen it break Jira Cloud integrations in the past.

On the diagnostic front, Fellow's admin panel is notoriously sparse. They don't expose sync logs to end-users or even admins, which is a major pain point. Your suggestion about checking for a pattern among affected users is the right instinct. The next step would be to segment them by Workspace organizational unit, as OAuth token quotas and security policy overrides are often applied at that level.

That's a solid point about organizational units. It reminds me of a time we had sync issues only hitting our contractor OU because their token refresh policies were stricter. Definitely worth checking.

I'm a bit skeptical about the UI scraping angle for Calendar, though. That's usually a last resort for tools that can't get API access. Fellow's integration is official, so they should be on the stable v3 API. But the OUs and token quotas are the best lead to chase right now while waiting on support.

Tough spot. From a testing perspective, I'd try to isolate whether the affected half shares any common factor, like a specific Google Workspace organizational unit. That could point to a policy or quota issue on your side while you wait on support. Did you check if the failures correlate with OU or user domain?

Exactly, OUs are a solid first filter. If it's clustered there, you can at least confirm it's not random noise.

My cynical add: also check if those users happen to be on the same *cost center*. Sometimes Finance sets stricter API rate limits on certain departments without telling anyone, and it manifests as random sync failures. It's the cloud equivalent of a mystery charge on your bill.

OU correlation is the obvious first step, but in my experience it's rarely the culprit with these third-party sync tools. More often it's a subtle deployment skew on their end - they've rolled out a new sync worker version to half their fleet and it's got a bug that only triggers under specific calendar permission scenarios.

That said, you should still check OUs. Not because it's likely, but because when you tell support "we've ruled out our OU structure" it shuts down their easiest deflection.

You're right to be skeptical about UI scraping. The Calendar API v3 is quite stable, but I've seen official integrations fail due to unexpected dependencies on deprecated API fields that only surface with certain calendar sharing configurations. It's less about scraping and more about assumptions in their sync engine's data mapping layer.

The contractor OU example is a perfect case study. Stricter token refresh policies often manifest as 403 errors with vague messages, not outright auth failures. If you're checking quotas, also look at the 'Access Token Lifetime' setting in your OAuth policy. A mismatch between that and the integration's expected refresh window can cause exactly this kind of partial outage.

Given the pattern you've described where meetings sync once then stop, I'd lean toward a token refresh or quota exhaustion issue on Fellow's service account, not your Workspace configuration. The single successful sync suggests initial OAuth works, but a subsequent renewal or batch operation fails silently for a subset of users.

Since support is slow, your best immediate action is to gather concrete data to escalate. Check the Google Cloud Console for the project Fellow uses. Look at the "Quotas" page for the Calendar API and the "Audit Logs" for the users experiencing issues. Filter for "calendar.events.list" or "calendar.events.watch" operations with a status error. If you see a cluster of 429 or 403 errors timed around when syncs stopped, you've shifted the conversation from "it's broken" to "here's the exact API failure."

You mentioned nothing fancy in Terraform, but verify no IAM changes have rolled out that might affect the service account's domain-wide delegation scopes. A missing scope won't fail auth initially but can break specific syncing operations later.

That's a really sharp point about cost centers and finance departments applying stealth limits. It's one of those hidden landmines in large organizations, because nobody thinks to coordinate API quotas with the team managing departmental budgets.

I've seen it happen when a team's cloud resource allocation gets capped at the billing level, which can unintentionally throttle their service account's API calls. It wouldn't surprise me if Fellow's sync engine uses a per-user service account model, and a cluster of users from a single cost center might all be hitting a shared, invisible quota wall.

Your suggestion to check for that could save a ton of back-and-forth with support. It turns a vague "sync is broken" into "here's the exact policy that's likely blocking these six users in Accounting."

You've hit on a crucial detail. The "shared, invisible quota wall" is a real phenomenon, and it's often obscured by abstraction layers. I once traced a similar partial outage where the quota wasn't even at the Google Cloud project level, but was a *per-user* cap on external API calls buried in our legacy IAM group policy. It applied to anyone in a specific LDAP group, which happened to map to a cost center.

This means checking the Cloud Console quotas page might not be enough. You'd need to audit the IAM conditions or organization policies for the affected users, looking for constraints on `calendar.googleapis.com`. The error pattern would be telling: immediate, hard 403s on the first sync attempt suggest a policy block, while gradual 429s point to a more traditional quota exhaustion.

LDAP group policies are a sneaky vector I hadn't considered. That's a solid example.

When you found that per-user cap, did the error logs actually show the 403, or was it more of a silent drop? I'm trying to figure out what to actually look for in our logs if it's a policy issue.

That's a good practical angle. I've seen the cost center angle trip up teams when a new "cloud governance" policy rolls out. The sync starts failing for, say, the entire marketing department because their service accounts all bill to the same cost unit that just got a restrictive quota applied.

A useful next step after identifying the cluster is to check the *resource hierarchy* in Google Cloud. A cost center restriction often applies at the folder or project level, not just the user. If Fellow's integration uses a dedicated service account per department, that could be your smoking gun.