# Webhooks 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](/flaky-tests/webhooks/linear-integration.md) and [Jira](/flaky-tests/webhooks/jira-integration.md) to automate ticket creation, and webhooks lets you build custom integrations for use cases that are not supported out of the box. [Svix](https://docs.svix.com/) powers webhooks for Trunk. You'll be using Svix to configure webhooks and you should familiarize yourself with the [Svix App Portal docs](https://docs.svix.com/app-portal) 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: {% embed url="" %} 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 | | `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 | You can also find guides for specific examples here:
Send a Slack Message/pages/44XqudmeHIp2KlHMt7F6
Create a GitHub Issue/pages/6Fx1b7YMfIOkWQKpCq41
Send a Microsoft Teams Message/pages/82zp7jrs4Y8ygSyQyo5F
Create a Linear Issue/pages/hPNMr88q9vk6u4Q1I8bk
Create a Jira Issue/pages/i4QNqnwGGFG7tgqEKVDn
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.trunk.io/flaky-tests/webhooks.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.