"The meeting ended twenty minutes ago and the survey still hasn't gone out."
If you've run automated meeting feedback for more than a few weeks, you've had a version of this message land in your inbox or Slack. The frustrating part isn't fixing it — it's that your system logs usually say the trigger fired fine. The calendar event ended, the job queued, the send function ran without an error. And yet the customer swears nothing arrived.
This is one of the more common support tickets for anyone running calendar-triggered automation, and it's worth understanding why it happens before you assume it's a bug in your send logic.
"No errors" doesn't mean "nothing went wrong"
A calendar-triggered survey depends on a chain of events that mostly happens outside your own code:
- The calendar provider (usually Google Calendar) has to notify your webhook that the event ended.
- Your app has to correctly match that event to the right meeting and attendee list.
- The send has to go out through email or another channel that isn't guaranteed delivery.
- The attendee has to actually have a working connection between their calendar and your account.
A failure at step 4 — a stale OAuth token, a disconnected calendar, a permission the customer revoked without realizing it — looks identical from your server's point of view to "everything worked." Your job ran, your API call returned 200, and the survey genuinely was sent — into a webhook that no longer had anywhere valid to deliver.
This is the category of bug that's nearly impossible to find in logs, because the logs are telling the truth. They just aren't telling you the part that matters.
Where to actually look
Start with the connection, not the send. Before assuming the survey trigger is broken, check whether the customer's calendar connection is still authorized. Revoked or expired OAuth grants are the single most common cause of "it worked before and now it doesn't," and they fail silently — nothing in your app necessarily flags that the token is dead until you try to use it.
Check event matching, not just event detection. If a customer has overlapping or recurring meetings, it's possible your webhook correctly detected that a meeting ended, but matched it to the wrong calendar event — meaning the survey trigger technically fired, just for the wrong meeting, and nothing sent for the one your customer actually cares about.
Rule out the obvious last: spam and delivery. It's worth checking, but it's rarely the actual cause once someone has already dismissed it — most people check spam before reporting the bug.
What we do when this happens to us
When a customer tells us a survey didn't send and our own logs look clean, guessing at the cause from the logs alone usually wastes more time than it saves. What actually settles it is watching the onboarding session where they connected their calendar in the first place — using UserTapes, which is session replay we point at our own onboarding flow. More than once, what looked like a backend delivery bug turned out to be a customer declining a calendar permission scope midway through connecting their account, closing the tab, and never coming back to finish. The trigger genuinely never had anything to fire from — the "bug" was in the setup step, three weeks earlier.
That's the pattern worth internalizing: a lot of "the automation is broken" reports are actually "the automation was never fully connected," and no amount of staring at send logs will show you that. You have to see the setup step itself.
The actual fix, once you know the cause
If it's a revoked or expired token, the fix isn't retrying the send — it's re-prompting the customer to reconnect, ideally with a status indicator that surfaces a broken connection before they notice a missing survey, not after.
If it's event matching on overlapping meetings, tightening how you match calendar events (attendee list plus start time, not just start time) usually resolves it without needing the customer to do anything.
Either way, the fix is specific to the actual cause — which is exactly why guessing from logs alone so often leads to the wrong change. Watching the real session where the connection was made (or wasn't) tends to be the fastest way to find out which one you're actually dealing with.