Flaky test webhooks in Trunk

Trunk provides webhooks for you to build custom integrations to automate workflows, like notifying your team when a test becomes flaky or automatically creating tickets to investigate flaky tests. Trunk provides built-in connectors for Linear and Jira to automate ticket creation, and webhooks let you build custom integrations for use cases that are not supported out of the box.

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.

Svix powers webhooks for Trunk. You’ll be using Svix to configure webhooks and you should familiarize yourself with the Svix App Portal docs to learn more.

Supported Events

Trunk lets you create custom workflows with event-triggered webhooks. Flaky Tests events are named with a test_case prefix. You can find all the events that Trunk supports in the event catalog:

Webhook Events | trunk.io - Svix

www.svix.com

Trunk publishes three Flaky Tests event types to Svix. Each event includes a full JSON schema with field descriptions visible in the Svix app portal.

`test_case.monitor_status_changed`

Emitted when a monitor activates or resolves for a test case.

Field	Type	Description
`type`	string	Always `test_case.monitor_status_changed`
`timestamp`	string (ISO 8601)	When the event occurred
`monitor.id`	string (UUID)	Unique identifier for the monitor
`monitor.type`	string	The type of monitor (e.g., `pass_on_retry`)
`monitor.status`	string	Current monitor status (`active` or `resolved`)
`evidence`	object	Data supporting the status change; structure varies by monitor type
`repository.id`	string (UUID)	Unique identifier for the repository
`repository.html_url`	string	URL of the repository
`test_case.id`	string (UUID)	Stable unique identifier for the test
`test_case.name`	string	Name of the test
`test_case.classname`	string	Test classname
`test_case.file_path`	string	File path of the test
`test_case.html_url`	string	URL to the test detail page in Trunk
`test_case.codeowners`	array of strings	Code owners associated with the test
`test_case.quarantined`	boolean	Whether the test is quarantined
`test_case.variant`	string	Test variant name

`v2.test_case.status_changed`

Emitted when a test case changes status (e.g., becomes flaky or is resolved), as triggered by a monitor.

Field	Type	Description
`type`	string	Always `v2.test_case.status_changed`
`timestamp`	string (ISO 8601)	When the event occurred
`previous_status`	string	The prior status of the test case
`new_status`	string	The updated status of the test case
`triggered_by.monitor_id`	string (UUID)	Unique identifier of the triggering monitor
`triggered_by.monitor_type`	string	Type of monitor that triggered the change
`triggered_by.monitor_status`	string	Status of the monitor at the time of the trigger
`repository`	object	See `repository` fields above
`test_case`	object	See `test_case` fields above

`test_case.investigation_completed`

Emitted when an AI-powered flaky test analysis finishes for a test case.

Field	Type	Description
`type`	string	Always `test_case.investigation_completed`
`investigation_id`	string (UUID)	Unique identifier for the investigation
`trigger`	string	How the investigation was initiated. One of `AUTOMATIC`, `MANUAL`, or `MCP`
`confidence`	number	Overall confidence score (0-1) for the findings
`created_at`	string (ISO 8601)	When the investigation completed
`markdown_summary`	string	Markdown-formatted summary of findings and recommendations
`failure_message`	string	The original failure message that triggered the investigation
`facts`	array	Facts discovered during the investigation
`facts[].fact_type`	string	Category of the fact (e.g., `GIT_BLAME`)
`facts[].content`	string	Detailed description with citations to supporting evidence
`facts[].confidence`	number	Confidence score (0-1) for this individual fact
`repository`	object	See `repository` fields above
`test_case`	object	See `test_case` fields above

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:

Flaky Tests

Webhooks

Supported Events

Webhook Events | trunk.io - Svix

`test_case.monitor_status_changed`

`v2.test_case.status_changed`

`test_case.investigation_completed`

Alert When a Test Escalates

Send a Slack Message

Create a GitHub Issue

Send a Microsoft Teams Message

Create a Linear Issue

Create a Jira Issue

​Supported Events

Webhook Events | trunk.io - Svix

​test_case.monitor_status_changed

​v2.test_case.status_changed

​test_case.investigation_completed

Alert When a Test Escalates

Send a Slack Message

Create a GitHub Issue

Send a Microsoft Teams Message

Create a Linear Issue

Create a Jira Issue

Supported Events

`test_case.monitor_status_changed`

`v2.test_case.status_changed`

`test_case.investigation_completed`