Skip to content
All posts

Integrating nreactive with Linear and Jira

Not every error should turn into a PR. A low-confidence fix from an automated pipeline consumes reviewer time without producing reliable value. The smart move in that case is to open a ticket in your existing tracker instead — the error is still captured, the pipeline still noticed, but the decision about what to do lives with a human. This post covers the Linear and Jira integrations we built for exactly that flow.

When the pipeline opens a ticket instead of a PR

Two conditions trigger ticket creation: the AI confidence score is below 0.6, or the analysis produces no applicable changes. Both mean the pipeline can't propose a concrete fix with reasonable confidence, so creating a PR would be theatre.

The ticket contains the same information a high-confidence PR would — root cause, confidence score, file and line, a stack preview — plus a note explaining why the pipeline stepped back. The human who picks it up has everything they need to investigate without re-reading the raw event.

Connecting Linear

Linear integration is the simpler of the two. In app settings, paste a Linear API key and pick a team id. The pipeline stores the key encrypted at rest, and whenever a low-confidence error lands on an app with Linear configured, a new issue gets created in the selected team. The issue title is prefixed with [nreactive] and the severity, followed by a truncated error message. The issue URL is written back to the error record so the dashboard can link directly to it.

Linear doesn't need OAuth for this flow — the personal API key is enough, and it scopes cleanly to the teams the key owner can access.

Connecting Jira

Jira is slightly more involved because Atlassian offers two auth modes. For Jira Cloud, OAuth is the recommended path: you click through the authorization flow, nreactive stores the access token and the cloud id, and from there the flow is the same — low-confidence errors create issues in the configured project. For self-hosted or legacy setups, basic auth with an API token works; you paste the host, the account email, the API token, and the project key.

The pipeline picks whichever credentials are available, prefers OAuth when both are present, and writes the issue URL back to the error record on success.

What the ticket looks like

The ticket body is three or four short Markdown paragraphs:

  • A one-line summary of the AI-inferred root cause.
  • The confidence score, rounded to the nearest percent.
  • The file and line the error fired in, when available.
  • A fenced code block containing the top 1500 characters of the stack trace.
  • A closing line explaining that the ticket was opened because AI confidence fell below the automatic-fix threshold.

That's it. The ticket isn't a design doc; it's a handoff note. Keep it small enough to read in a glance.

Failure modes

Integrations can fail, and the pipeline shouldn't wedge when they do. If ticket creation fails — wrong credentials, revoked access, tracker downtime — the error is logged and the original error record transitions to "fix_generated" anyway so the dashboard reflects that analysis ran. The next time the same fingerprint fires, the pipeline tries again.

Silent failures would be worse than noisy ones, so we log the failure reason and surface it in the activity log with enough detail for a human to debug without leaking credentials.

Per-app versus per-user

Integrations live on the user record, not the app record. That means a single user with multiple apps shares one Linear key and one Jira connection across all of them. The team or project id is still on the user record, so every app uses the same routing. This is a deliberate simplification — if an app really needs a different tracker destination, the cleanest workaround is a separate user. Multi-destination routing per app is on the roadmap.

What the integrations don't do

Integrations don't close tickets automatically. When a follow-up run of the pipeline produces a successful fix, the ticket stays open with a note that a PR was created. Closing the ticket is a human decision — the workflow conventions vary enough across teams that automation would cause more friction than it saves.

Integrations also don't sync back status. If you close a ticket manually, nreactive doesn't notice. If that matters for your workflow, reach out via contact and we'll scope the right hook.

Setup check

After connecting Linear or Jira, the fastest way to confirm the wiring is to trigger a low-confidence error on a staging app. You should see an issue land in the tracker within a few seconds, with the URL reflected on the error record in the nreactive dashboard. If nothing appears, the activity log is the first place to look for the failure reason.