Morgan Vernay, Engineer on the Foundation Team at Cal.com, shares how Trigger.dev became core infrastructure for Cal.com: millions of runs a month covering booking orchestration, calendar syncing, an AI agent for phishing detection, and fraud analysis.
Cal.com at scale
Cal.com is scheduling infrastructure. It powers booking for everything from solo consultants to enterprise sales teams, and at the enterprise end the bar is high: confirmations have to feel instant, and even a 1 second delay on the booking itself is noticeable.
I'm on the Foundation team. We own exchange infrastructure, the global architecture, and the projects that touch everything underneath the product surface. Trigger.dev sits at the center of a lot of that.
Why we needed Trigger.dev
Confirming a booking on Cal.com isn't a single write. It fans out into webhooks, transactional emails, SMS notifications, calendar API calls (Google and Microsoft Graph), Salesforce event creation for enterprise accounts, billing updates, fraud checks, and a handful of integrations on top. All of it is critical to the booking experience.
We needed a workflow engine that could handle that fan-out, scale through bursts, and stay inside the rate limits of the APIs we depend on (Google Calendar quotas in particular are something we think about a lot).
We looked at several options. Trigger.dev was the one we picked.
The documentation was super on point and clean, and the dashboard was very easy to use from day one. The developer experience and the setup process were the biggest reasons we chose it.
Integrating it into our monorepo was simple, even with our Prisma layout, and we had real workflows running in production within days.
How we use it
What's worked best for us is keeping run payloads small. Instead of stuffing a full booking record in, we pass identifiers and let the workflow refetch what it needs. Payloads stay tiny, PII stays out of Trigger.dev, and a replay always runs against the latest state of the data.
Booking orchestration
Booking confirmations, reschedules, and cancellations kick off an orchestrator workflow that fans out to email, SMS, webhook delivery, calendar updates, and the rest. The orchestrator handles durability and retries, so the user sees their confirmation immediately and nothing downstream gets dropped.
Catching phishing with an AI agent
We get hit with a lot of booking spam. Sometimes 1,000+ fake bookings in a single wave, often with phishing links in the notes field.
For suspicious bookings, we run an AI agent that opens the links in a browser and analyzes what it finds. Each scan takes around 40 seconds, and because it lives inside a Trigger.dev workflow we don't have to think about timeouts or where it runs. If a link gets flagged, we block the booking and shut down the account.
Fraud and user behavior analysis
Alongside the phishing agent, we have workflows that look at user behavior patterns across bookings and surface anomalies for our fraud review. Those would have been awkward to run inline.
Calendar syncing with Google and Microsoft Graph
When a calendar event changes on the customer's side, Google or Microsoft posts a webhook to us, and we have to reconcile state for the affected account. We process these as durable workflows with concurrency keys and idempotency, so a burst of webhooks for one account collapses into a single reconcile pass. That alone has done a lot to keep us inside Google's quota.
Salesforce, billing, and the long tail
Salesforce event creation for enterprise customers, automated billing workflows, and subscription updates also live in Trigger.dev. Anything that touches a third-party API and isn't strictly required to be in the critical path runs here.
What changed
The booking flow no longer waits on side effects. Enterprise customers see confirmations land in the sub-second range we've committed to, and the system stays inside its rate limits even during attack waves.
Replays have changed how the team feels about incidents. If something fails, we replay the affected runs in a batch and move on. Nobody is dreading the on-call pager the way they used to.
The biggest architectural win has been the combination: small payloads, concurrency keys, and replay together. We can scale because every failure mode collapses back to "rerun the workflow." We're processing millions of runs a month today, with several million more on the way as we expand calendar syncing coverage.
What's next
A few things we're building toward:
- Realtime in the frontend. Progress bars on long-running exports and streaming updates from in-flight runs back into the Cal.com UI.
- Calendar syncing expansion. Our calendar sync workload is about to add several million more monthly runs as we extend coverage.
- Native AI agents. We're running a lot of AI work inside Trigger.dev today (the phishing agent is one example), and we're looking at moving more of our custom agent code onto Trigger's agent primitives.
The bar we had for Trigger.dev was simple: run a lot of stuff for us, reliably, without us having to babysit it.
