Status checks (Check Run / Build Status)

When a CI pipeline fails and Exlogare runs the AI root-cause analysis, we publish two things back to the host:

1. A comment (the existing cascade: PR/MR comment → commit comment → Issue), which contains the full RCA.
2. A status check (this page) — a single green/red entry next to the failing commit with a one-line summary that deep-links to the analysis on the Exlogare dashboard.

The comment is the rich, stable surface. The status check is the glance-able signal that the developer sees in the PR header without having to scroll through the comment thread.

What surfaces it lands on

Provider	API surface	Where the developer sees it
GitHub.com / GHE	POST /repos/{owner}/{repo}/check-runs (REST)	Checks tab on the PR; required-checks UI; commit page
Bitbucket Cloud	POST /2.0/repositories/{ws}/{slug}/commit/{sha}/statuses/build	Build statuses widget on the commit; PR header
Bitbucket DC	POST /rest/build-status/1.0/commits/{sha}	Build statuses widget on the commit; PR header
GitLab	Not enabled in the current release. The MR-note cascade still posts the full RCA on GitLab failures.	—

The key on Bitbucket and the name on GitHub are both exlogare/rca. Re-publishing for the same commit updates the existing entry rather than spawning a duplicate, so a re-run won’t pollute the commit page.

What appears in the entry

• Title: Exlogare RCA - <SEVERITY> severity (e.g. Exlogare RCA - HIGH severity).
• Summary / description: the first line of the AI’s root_cause, truncated to 140 chars on Bitbucket. GitHub also gets a longer multi-paragraph summary (root cause + fix suggestion + missing-context hint).
• State / conclusion:
  • GitHub: failure for severity high, action_required for medium, neutral for low. We never claim CI itself failed (it already did) — we report the severity bucket Exlogare classified the failure into.
  • Bitbucket: FAILED for severity high, STOPPED for everything else. Bitbucket only allows a closed set of states, so this is the closest mapping we can do without lying about the build itself.
• URL / details_url: points to /dashboard/analyses/<id> so one click takes the developer to the full RCA.

How to enable / disable it

Status checks are on by default on every plan. You can flip them off at two levels:

1. Team-level kill switch. Settings → Feedback channels → “Commit status check”. Turning this off disables the channel for every project in your tenant.
2. Per-connection override. Integrations → (project) → Feedback channels → “Status check on commit”. Useful if you want comments on a noisy mono-repo but no extra checks blocking the merge UI.

The two are AND-combined: a per-connection opt-in cannot override a team-level opt-out. This matches how the comment cascade is gated.

Required permissions

• GitHub: the connection’s token (App or PAT) needs the checks:write scope. OAuth-only tokens issued through our default app already have it. If your org installed the app with custom scopes, the API will return 403 Forbidden and we’ll silently skip the status check — the comment cascade still runs.
• Bitbucket Cloud: the OAuth scopes registered for our app (pipeline, repository, pullrequest) include build-status writes. No extra step.
• Bitbucket DC: the Personal Access Token used by the connection needs REPO_WRITE on the repository. The endpoint /rest/build-status/1.0/commits/{sha} is enabled by default on supported DC versions.

Failure modes

The status check is fire-and-forget: HTTP errors during posting are logged but never abort the comment cascade. In practice you’ll see this if:

• The connection token lost the checks:write permission (GitHub).
• The commit SHA is unknown to the host yet (rare; happens if our webhook delivery races the push).
• You disabled the channel at the team or per-connection level.

The audit log records both the comment ref and the status-check ref under meta.status_check for every successful post, so you can verify what landed where.

Example: minimal payloads we send

GitHub Check Run:

{
  "name": "exlogare/rca",
  "head_sha": "<sha>",
  "status": "completed",
  "conclusion": "failure",
  "details_url": "https://app.exlogare.net/dashboard/analyses/<id>",
  "output": {
    "title": "Exlogare RCA - HIGH severity",
    "summary": "**Root cause:** ConnectionError to pypi.org\n\n**Fix suggestion:** ..."
  }
}

Bitbucket Build Status (Cloud):

{
  "key": "exlogare/rca",
  "state": "FAILED",
  "name": "Exlogare RCA - HIGH severity",
  "description": "ConnectionError to pypi.org during pip install",
  "url": "https://app.exlogare.net/dashboard/analyses/<id>"
}

See also

• Failure clusters — recurring issues drive a “×N” badge inside the comment; the status check entry stays single-shot per commit.
• Outbound webhooks — for piping the same RCA into PagerDuty / Sentry / your own system.
• GitHub Actions ingest and Bitbucket OAuth — the connection options that allow Exlogare to publish status checks back to your repo.