Debugging bookings shouldn't require a support ticket
Per-booking webhook and workflow logs are now available directly from the Bookings page — so you can see exactly what fired, what failed, and what to do about it.
When a booking silently misbehaves — a Zap didn't run, a CRM record didn't sync, a reminder email never went out — the first question is always the same: what actually happened? Until now, answering that meant digging through third-party dashboards, correlating timestamps, and guessing which webhook attempt corresponded to which meeting. It was slow, and it put the burden of forensics on the person least equipped to do it: the person whose meeting broke.
Logs, scoped to a single booking
We're shipping per-booking log inspection. Open any scheduled meeting from your Bookings page and you can now see the webhook and workflow activity tied to that specific booking View Booking Logs. Not an org-wide firehose, not a global event stream — the events for this meeting, in one place.
The scoping is the point. Most log tooling gives you everything and asks you to filter down. For booking issues, you almost always start from the other direction: a specific meeting, a specific attendee, a specific complaint in your inbox. Starting from the booking itself matches how the problem actually arrives.
What it unlocks
A few things get easier immediately:
- Confirming delivery. You can see whether a webhook fired and what the receiving system returned, without leaving the app.
- Diagnosing workflow gaps. If an automation didn't run — or ran but didn't do what was expected — the trail is right there next to the booking that triggered it.
- Handing off cleanly. When you do need to escalate to your ops team or to us, you have concrete evidence instead of "I think it didn't send?"
The common thread: fewer round-trips between people and tools to answer a question that should have been answerable in one click.
What's next
This is the first cut. We're paying attention to which log types people reach for most, and where the current view still forces context-switching to an external tool. Expect richer filtering, more event detail, and tighter linking between logs and the workflows that produced them in follow-up releases.