Triage

Triage is Runway's centralized, automated "inbox" for issues. It consolidates issues such as regressions flagged by QA, feedback from beta testers, reviews from users in the app stores, new crashes, unhealthy metrics, and other connected sources into one view. From there, it routes issues to the right owner, flags duplicates and related issues, and streamlines the fix request process within Runway.

Triage is accessible in two places, both backed by the same underlying data:

• App level: an aggregate view across all releases for an app.

• Release level: scoped to a specific release, for teams triaging issues for a version currently in flight.

Within either view, issues can be filtered or sorted by status, owner, date, or destination (which app the issue is associated with), so you can quickly separate what needs attention from what's already assigned, in progress, or resolved.

Triage is available on paid plans only.

Sources in Triage

A source is the origin system or signal that produced an issue in Triage. Runway currently supports the following source types in Triage:

Runway will pull in these sources if they are connected to Runway and part of your subscription tier.

• Regression testing results

• Beta testing feedback submitted via TestFlight

• User reviews in App stores

• Unhealthy health metrics detected via Stability monitoring and Observability & analytics integrations

• Self-reported issues created either within Runway, or via the MCP.

• Project management tickets

Currently, Triage supports tickets from Jira and Linear. By default, Runway will automatically pull in tickets with a label or issue type `Bug`. Learn more about additional settings here.

Issue lifecycle

Every issue moves through a defined set of states as it's triaged and resolved:

Status	Meaning
New	Detected (or manually created) and awaiting triage. Available actions: request a fix, or mark not a priority.
Fix requested	A fix request has been opened against the issue.
Resolved	Either the associated fix request was approved and merged, or the issue was manually resolved.
Unresolved	A fix request was rejected; the issue is given an Unresolved state.
Not a priority	Manually deprioritized; moves the issue into the closed bucket.

An issue counts as closed if it's in any of:

• Not a priority

• Resolved

• Unresolved

Note that reopening a closed issue returns it to New.

Every issue state transition results in a timeline event and, if configured, fires a Slack/Teams notification informing your team of the issue’s new state.

These notifications will automatically go to your Primary channel but you may want to set up a channel override within the New triage issue identified and Triage issue status updated notifications to send these updates to a separate channel.

Routing and ownership

If you enable the Assign users to issues detected in Triage automation, for every new issue, Runway will suggest an owner automatically by looking across signals such as:

• Authorship of associated pull requests

• Owners of previous related issues

• Linked tickets that already have an assignee

When one clear candidate emerges, Runway auto-assigns them. When there are multiple plausible owners, Runway assigns its best guess but surfaces the other candidates so the assignment can be easily overridden.

Duplicate, related issue, and potential causes detection

Every new issue is checked against existing issues, both open and closed, to surface:

• Duplicates, which are merged into the existing issue (reopening it first, if it was closed)

• Related issues, which are surfaced with links to any work that already resolved them

• Potential cause: when possible, Runway will proactively suggest an explanation for why an issue occurred and link to the relevant underlying data source for your team to use during their investigation.

This lets teams act on precedent instead of re-investigating a problem from scratch.

Taking action

Everything needed to act on an issue lives in Triage:

• Assign a target fix version directly from the issue.

• Create a fix request and link it to a code change and/or a Project management ticket.

• If you enable the Create issue tickets from Triage in project management tool automation, Runway will auto-create a ticket pre-filled with what it already knows about the issue.

• As a fix moves from requested → approved → merged → released, the issue's status updates automatically, and configured Slack/Teams notifications keep stakeholders posted along the way.

Triage is also exposed via the MCP, so agentic coding tools can query open issues before starting work, create or update issues, and request fixes, without a human relaying context back and forth.

Settings and permissions

Org admins can configure which source types should feed Triage by navigating to Org settings > Triage. By default, all source types are enabled.

If you wish to adjust the types of tickets that Runway pulls in from your Project management tool, navigate to App settings > Integrations > Project management and add or edit the Triage filter options.

Of note, Runway will apply the following logic to Triage filter options:

• If Runway detects any of the options found in Issue type or Label within a ticket, Runway will pull the ticket into Triage.

• If a Title keyword is also set, then Runway will only pull in tickets where it detects the Title keyword and either the Label or Issue type.

Additionally, users with the Manage Triage issues permission can click into a Triage issue and update:

• Issue state

• Assignee(s)

• Reporter(s)

• Data source(s)

• Latest build detected

• Latest version detected

• Target fix version

All other users have read-only access to Triage. They can:

• Filter and sort the Triage view

• Create a new triage issue manually, selecting its data source(s) from a dropdown