Creating tickets in Linear or Jira? Trunk’s built-in automatic ticketing is the recommended approach — it produces richer ticket bodies (failure history, impact, common failure reasons, code owners), manages the full ticket lifecycle (create, reopen, close), and has full dashboard support with tickets linked back to their test cases. Use webhooks for custom workflows or platforms without a built-in integration.
For Merge Queue webhook events (
pull_request.* and pull_request_batch.*), see the Merge Queue webhooks reference.Supported Events
Trunk lets you create custom workflows with event-triggered webhooks. Flaky Tests events are named with atest_case prefix. You can find all the events that Trunk supports in the event catalog:
Webhook Events | trunk.io - Svix
Test collection events
Events for test collections carry the same event types, with one addition to the payload and one thing you cannot do with it. Telling the two apart. A collection event carries atest_collection object — its ID and a link to the collection. Repository events don’t. That object is the supported way to distinguish them.
You cannot deduplicate on test_case.id. Collection and repository events do not share a test-case ID space, so the same underlying test arrives under two unrelated IDs. repository.id is the only handle common to both, and it is omitted rather than guessed when an upload carries no repository.
While you are migrating, collection events are off. A repository and a collection with monitors over the same tests detect independently, so one detection can produce two events. Switch collection events on from Settings → Organization → Webhooks once your consumer handles the payloads above. It is one switch for every collection event, not one per event type, and it disappears once you have finished migrating — at that point collection events are simply sent. See the migration guide.
Event payloads
test_case.monitor_status_changed
Emitted when a monitor activates or resolves for a test case.
v2.test_case.status_changed
Emitted when a test case changes status (e.g., becomes flaky or is resolved), as triggered by a monitor.
test_case.investigation_completed
Emitted when an AI-powered flaky test analysis finishes for a test case.
Citations in
markdown_summary and facts[].content are delivered as fully rendered links to the supporting evidence, so you can consume these fields directly without resolving placeholder tags.
Delivery reliability. If the webhook delivery provider rate-limits a request, Trunk automatically retries with exponential backoff, so a transient spike rarely drops an event. This applies to every Flaky Tests webhook event and needs no configuration on your side.
You can also find guides for specific examples here: