Trigger.dev
Build and deploy fully‑managed AI agents and workflows
5.0•20 reviews•825 followers
Build and deploy fully‑managed AI agents and workflows
5.0•20 reviews•825 followers
Trigger.dev is the platform for building AI agents in TypeScript. Everything you need for durable agents: retries, queues, observability, and elastic scaling.
This is the 4th launch from Trigger.dev. View more
Trigger.dev: Webhooks for your AI agents
Launched this week
Trigger.dev Webhooks let you build AI agents on top of the services your customers already use, like Slack, Supabase and Stripe. A GitHub pull request can start a code review agent, a new Sentry issue can start an agent that writes the fix, and a Stripe refund can wait for a human to approve it in Slack.
Free Options
Launch Team / Built With
![Trigger.dev Realtime AI [LW24]](https://ph-files.imgix.net/415afe48-f35c-4e64-8902-4b5994ca10c7.jpeg?auto=compress,format&codec=mozjpeg&cs=strip&fit=crop&frame=1&h=48&w=48)
Hey Product Hunt 👋
For a long time, webhooks has been the number 1 most requested feature on Trigger.dev.
Today it's live - you can now start, resume or message your AI agents from webhooks sent by Stripe, GitHub, Slack, Supabase and 50+ others.
Every webhook is stored before it’s processed, so none are lost, and it’s all open source.
Excited to see what you build https://tgr.dev/webhooks-ph
The resume/message distinction is the part I keep coming back to. When a webhook arrives for an agent that's already running, does it queue as a message for the current run, or start a separate one? And when it resumes a waiting agent, does the agent get the stored webhook payload as its only new context, or the full event history for that run? That boundary matters a lot once a Slack approval comes back days later and the original request has moved on.
this looks really useful. I have hacked together webhook to agent setups before and it always turns into a mess of retries and timeouts. I have a question, if an agent is waiting on a Slack approval and nobody responds for a couple of days, does the run just sit there or can you set a timeout?
Congrats to the team!
The webhook arriving twice is annoying. The agent issuing the refund twice is expensive. How do you handle duplicate events and retries when the next step has a real-world side effect?
A stored webhook gives you a useful starting point when an agent takes a wrong turn. I'd want to inspect that original event alongside the run it started.
The orchestration and retry logic are the real moat here. Building reliable agent workflows is hard - network timeouts, LLM rate limits, cascading failures. A platform that abstracts job queuing, observability, and dead-letter handling changes the math on what's actually deployable vs what stays a notebook. Curious about the serverless pricing model and how it scales with high-frequency agent tasks.