You can now automatically create Jira issues when a test becomes flaky.
A new Jira connector in your webhook settings creates issues in your Jira Cloud project whenever a test's status changes to flaky and impacts more than a configurable number of PRs. This mirrors the existing Linear webhook integration. Configure your Jira project key, issue type, labels, and custom fields, and issues are created with full test context including failure rates, codeowners, and links back to the Trunk test detail page.
The Get Testing Details API now returns impacted target information, giving CI systems everything they need to launch the right tests. Previously, teams using impacted targets had to piece together information from multiple API calls to figure out which targets a PR affects and which tests to run. Now a single API call returns impacted targets alongside queue position, dependent PRs, and batch membership, so your CI can make informed decisions about test scope without extra round-trips.
The Trunk Slack App Home tab is now a full control plane for your merge queue activity across all your organizations. The Home tab shows your active and recently merged PRs, notification preferences, and account linking status, all within Slack. Changes you make here (like toggling a notification topic) sync back to the web UI automatically, and vice versa. The app now installs at the workspace level, so your coworkers get access without each needing to install it individually.
You can now run multiple merge queues in the same repository, each targeting a different branch. Previously, a repo could only have one queue. Now you can create additional queues from the merge queue creation page. The repo selector shows repos that already have queues and how many exist. The settings page supports switching between queues via a branch selector with colored state indicators (green = Running, yellow = Paused). The dashboard selector groups repos with multiple queues so you can tell them apart at a glance.
You now have full control over how flaky tests are detected. Threshold monitors let you define exactly when a test should be flagged as flaky or broken, set the failure rate threshold, time window, minimum sample size, and which branches to watch. A live preview panel shows you exactly which tests would be flagged under your current settings before you save, so you can tune detection rules with confidence.
Merge queue Slack notifications can now be routed to multiple channels. Previously, notifications went to a single configured channel. Now you can add multiple channels from your org's notification settings, each channel can be independently enabled or disabled for specific notification topics. The channel picker loads your Slack workspace's channels directly, so you no longer need to re-auth or manually enter channel names.
A new POST /v1/listPullRequests endpoint lets you query all PRs in your merge queue programmatically. Filter by state (not ready, pending, testing, merged, failed, cancelled), time range, and paginate through results. This gives CI integrations and internal tooling a complete view of queue activity without scraping the UI.
Example Request
1curl -X POST https://api.trunk.io/v1/listPullRequests \
Merge Queue now exposes a Prometheus-compatible metrics endpoint for integration with your existing monitoring stack.
Previously, merge queue metrics were only available through the Health tab in the Trunk web app. Now you can query GET /v1/getMergeQueueMetrics (authenticated via x-api-token header) to pull real-time queue data into Prometheus, Grafana, Datadog, or any tool that scrapes Prometheus-format metrics.
PRs can now opt out of batching to test in isolation. When a high-risk PR is in the queue, batching it with other PRs means a failure forces the entire batch to restart. With the new noBatch flag, a PR tests on its own, protecting other PRs from being delayed by its potential failures. Set it via the /trunk merge --no-batch CLI command or by passing "noBatch": true in the POST /v1/submitPullRequest API request.
The merge graph now shows impacted targets directly on nodes and edges, so you can see exactly why PRs are connected and which targets they share.
Toggle "Show targets on hover" in the graph toolbar to see per-PR impacted targets on each node, shared targets between connected nodes, and intra-batch overlaps. You can also view the full impacted target list for any PR via a "View Impacted Targets" modal with a downloadable JSON export.
You can now customize the merge commit title for any PR in the queue. Add merge-commit-title: Your custom title here on its own line anywhere in your PR body, and the merge queue will use that as the commit title when merging instead of GitHub's default. If you don't include the directive, the default format (PR Title (#123)) is used as before.
Programmatically create, configure, and manage merge queues via REST API
You can now fully manage your merge queues through the Trunk API without touching the web UI.
Create new queues with /createQueue, specifying your target branch, mode (single or parallel), and concurrency settings. Update queue configuration on the fly with /updateQueue—adjust concurrency, enable batching, set testing timeouts, pause or drain the queue, and more.
Query queue status with /getQueue and clean up with /deleteQueue when a queue is no longer needed.
This opens up powerful automation possibilities: spin up queues for new release branches as part of your release process, dynamically adjust concurrency based on CI capacity, integrate queue management into your infrastructure-as-code workflows, or build custom dashboards using queue data. Teams managing multiple repositories or complex branching strategies can now script their entire merge queue infrastructure instead of clicking through settings one by one.
When infrastructure issues like database outages, network problems, or CI runner failures cause a large number of tests to fail simultaneously, retrying those tests can trigger mass false flaky detections. Infrastructure Failure Protection identifies these scenarios and excludes them from flakiness detection.
By enabling this setting, you can set a threshold for filtering runs based on the percentage of failed tests; if failures exceed 80%, those tests won't be processed for flaky test detection and you'll see a new status in the Uploads tab indicating 'Upload Skipped Due to Infrastructure Error'.
Get direct messages in Slack about your PRs in the merge queue, keeping you informed without adding noise to team channels and allowing you to address failures immediately.
Receive personalized Slack DMs when your PRs are queued, start testing, pass tests, get merged, or encounter issues. By linking your GitHub account to your Trunk account and configuring your notification preferences, you'll stay up-to-date on the progress of your code through the merge queue without needing to check the web UI or monitor shared channels.
This means you can focus on your work while staying informed about your own PRs, get immediate alerts when your PR fails so you can address issues right away, and reduce noise in team channels by keeping personal updates private. Whether you're waiting for a critical hotfix to merge or just want peace of mind about your code's progress, personal notifications ensure you never miss an important update about your pull requests.
To get started, navigate to User Settings > Notifications, connect your GitHub and Slack accounts, and choose which events should trigger notifications. You can customize exactly which updates you want to receive, from every stage of the merge process to just the critical events like failures and successful merges.
Choose how your PRs get merged: squash, merge commit, or rebase.
You can now select your preferred merge method for PRs going through the merge queue. Previously, Trunk Merge only supported squash merging, which combines all commits into a single commit. Now you can choose between:
Squash (default) - Combines all commits into a single commit
Merge commit - Preserves all individual commits and creates a merge commit
Rebase - Replays commits on top of main for a linear history
This flexibility means you can match your team's existing Git workflow preferences, maintain your desired commit history style, and satisfy different requirements across projects. Whether you want a clean linear history with squash, full commit preservation with merge commits, or a streamlined history with rebase, your merge queue now adapts to your team's practices instead of forcing you to change them.
Analyze merge queue performance for specific parts of your codebase
Now you can filter merge queue health metrics by impacted targets to see exactly how well this parallel workflow is performing for each part of your codebase. For example, in a TypeScript/Python monorepo, you can view metrics specifically for TypeScript PRs versus Python PRs, identify if one team is experiencing slower merge times than another, and optimize queue configuration for your highest-priority code paths.
This visibility helps you demonstrate the value of parallel mode to engineering leadership, ensure fair queue performance across teams, and make data-driven decisions about how different parts of your codebase move through the merge process and priorities.
Skip redundant testing and merge immediately when your PR is already up-to-date and the queue is empty
The merge queue exists to test your PR against the latest version of main, but if your PR is already based on the tip of main and the queue is empty, rerunning tests provides no additional value; you've already tested against the exact state your PR will merge into.
With this optimization, Trunk Merge Queue will recognize this situation and merge your PR directly without the unnecessary wait.
Set higher test concurrency for failure isolation without slowing down your main merge queue
When a batch of PRs fails and needs to be split apart to identify the culprit, you want those bisection tests to run as fast as possible so developers get quick feedback about what broke.
Previously, bisection tests shared the same concurrency limit as your main queue, meaning the isolation process could slow down other PRs waiting to merge. With independent concurrency settings, you can configure bisection to run at higher concurrency (spinning up more test runners to isolate failures ASAP) while keeping your main queue at its optimal setting.
This means faster root cause identification when batches fail, no impact on your main queue's throughput during failure investigation, and the flexibility to optimize each workflow independently. You can be aggressive about isolating problems without sacrificing the steady flow of successful PRs through your queue.
Intelligently reuse test results when isolating failures in batched PRs to save CI resources
When you use batching mode, the merge queue tests multiple PRs together for efficiency. If a batch fails, the queue needs to figure out which specific PR caused the problem by splitting the batch apart and retesting smaller groups.
With this optimization, the merge queue will recognize when it's about to run a test that it has already run during the isolation process. If we already know a test will fail based on earlier results, we skip rerunning it and reuse that information.
This means faster failure isolation when batches break, significant CI cost savings during the bisection process (especially important for large batches or expensive test suites), and quicker feedback about which PR needs fixing.
