Troubleshooting

Google Calendar Connected, But Agent Can’t Create Events?

A fast, proof-first workflow to fix “connected but won’t create” loops without burning time on reconnect retries.

Common pattern: the connector shows as connected, the agent can sometimes read calendars, but event creation fails, silently does nothing, or lands on the wrong calendar/day.

Reality check: “Connected” is not write proof. You need one successful canary create + read-back in the exact calendar, account, and timezone you actually use.

Fast path (4 steps)

1) Lock the exact calendar + timezone first

Most failures are default-calendar mistakes. Tell the agent the exact calendar name, event timezone, and date format before it tries to write.

2) Run a tiny canary event create

Create one short test event (for example, 10 minutes) with a unique title like CAL-CANARY-2026-04-05-1430.

3) Require immediate read-back proof

Don’t accept “done.” Require calendar name, event ID, start/end time, and timezone from the write result or follow-up fetch.

After creating the event, return: 1) calendar name used 2) event title 3) start + end with timezone 4) event ID or link If create fails, return exact raw error text.

4) Only then scale to real scheduling

After one canary succeeds in the same session/surface, move to production reminders and recurring workflows.

Copy/paste recovery prompt

My Google Calendar shows connected, but event creation is unreliable. Do this exactly: 1) Confirm authorized Google account and exact calendar name you will use. 2) Create ONE 10-minute canary event titled CAL-CANARY--. 3) Return write proof: calendar name, event title, event ID/link, start+end with timezone. 4) Immediately read back that exact event and confirm it exists. 5) If anything fails, return exact raw error text and do NOT reconnect unless you show a specific auth/scope error first.

High-friction failure patterns

Wrong calendar target: agent writes to default calendar while you check a team/shared calendar.
Timezone drift: event is created, but appears at an unexpected hour/day so users think it failed.
Draft-vs-create confusion: agent outlines an event plan but never actually executes a write call.
Cross-surface mismatch: connected in one surface/session, tested in another with different auth state.

Advanced edge cases (when basics pass but creates still fail)

Insufficient write scope: OAuth completed with read-only scope; reads work, writes fail.
Workspace admin restrictions: org policy allows calendar view but blocks third-party writes.
Shared calendar permissions: account can view shared calendar but lacks “make changes to events.”
Recurring-rule validation errors: RRULE or invalid date format causes silent/opaque create failures.
All-day/DST drift: all-day events or daylight-saving transitions can appear on the wrong day if timezone isn’t explicit.
Attendee/invite policy failures: some org calendars allow event creation but block guest invites or external attendees.
Duplicate events from retries: users retry after a delayed response and create duplicates; require idempotent canary titles.

Loop-break rules

Stop reconnect spirals: one reconnect max per diagnostic cycle. If canary create + read-back still fails, escalate once with exact evidence.

What to include if you escalate

Authorized Google account shown by the agent
Exact calendar name targeted
Event payload used (title, date, start/end, timezone)
Whether event was timed vs all-day and whether attendees were included
Surface/context used (dashboard, DM, server channel, thread)
Exact raw error message (no paraphrase)

Bottom line: prove one canary create + read-back in the right calendar and timezone. If that fails, escalate with exact evidence once—don’t keep reconnecting blindly.