I've been evaluating MeetGeek for the last quarter as part of a broader initiative to streamline meeting documentation and knowledge retention across our engineering teams. On paper, the promise of automated recording, transcription, and syncing from Google Meet is compelling from a FinOps and operational efficiency standpoint. However, I'm encountering a persistent and critical failure point that undermines its core value proposition: **recordings are failing to sync approximately 30% of the time.**
The pattern isn't random. It appears to be correlated with:
* Meetings that exceed 60 minutes in duration.
* Meetings where the recording is initiated *after* the meeting has started, rather than being set from the calendar invite.
* Instances where a Google Meet recording is saved to a shared drive where the MeetGeek service account has `viewer` permissions but not explicit `content manager` or `editor` roles.
The symptom is consistent within the MeetGeek dashboard: the meeting appears, the transcription tab is present, but the "Recording" section perpetually states "Processing..." before eventually disappearing or showing an error icon. The raw Google Meet recording, however, is perfectly accessible in the designated Google Drive folder.
I've engaged with support, and their troubleshooting has been superficial—the standard "re-authenticate the calendar and drive integrations." This is a band-aid that works for one or two meetings but doesn't address the systemic sync failure. The lack of detailed logging or a true admin panel to see the sync queue/errors is a significant observability gap.
Has anyone else in the community performed a deep dive on this? I'm looking for concrete data points.
* **What's your Google Workspace admin configuration** for the service account? (e.g., API scopes, domain-wide delegation settings)
* **Have you identified any specific Drive folder structures or permission models** that guarantee reliability?
* **Are you using a specific OAuth consent screen configuration** (internal vs. external) that seems more stable?
* **Is there a known latency or queueing issue** on MeetGeek's side for processing longer recordings?
I'm preparing a detailed incident report for our vendor management, and community data would be invaluable to move this from anecdotal complaints to a demonstrable, reproducible bug. The cost of manually tracking down and linking missing recordings is currently negating the ROI we projected.
-- alex
Oh man, the point about permissions on the shared drive is so key, and something I've run into with other sync tools too. It's easy to think a service account with viewer access to the folder is enough, but Google's own processing of recordings seems to require higher privileges for the final file to be "settled" and readable by an external app. I've had to explicitly grant "Editor" on the destination folder for my own integrations to work reliably.
Your 30% failure rate on longer meetings also tracks with what I've seen in a different context, using the Google Drive API directly. It feels like there's a silent timeout or a race condition on the backend when a recording file is very large. Did your team try implementing a delayed sync, like a 10-minute wait after the meeting end time before attempting the pull? That crude workaround helped us a bit, for whatever reason.
Spreadsheets > opinions