GitHub & Jira integrations

Connect your issue tracker so the loop closes itself: link an incident to a GitHub or Jira issue, and when that issue is fixed and the release reaches production, error.page automatically resolves the incident and emails the users who opted in during the outage — "we're back." Integrations are a Business-plan feature, configured per organization by an owner or admin under Team → Integrations.

The model: fixed and released

Resolution requires both signals, so nobody gets a premature "we're back":

1. Fixed — the linked issue is closed (GitHub) or moved to a Done status (Jira).
2. Released — a production deploy succeeds (GitHub) or the issue's fix version is released (Jira). Or you tell us directly with the release webhook.

When both are true, the incident is resolved (recovery time recorded), the incident.resolved webhook fires, and opted-in users are notified. It's idempotent — a re-delivered webhook never double-resolves or double-emails.

Linking issues

On any incident, use Link issue to attach an existing GitHub/Jira issue, or Create issue to open a new one pre-filled with the error type, affected users, a link back to the incident, and the deduplication fingerprint. An incident can carry several links.

GitHub

1. Connect — Team → Integrations → GitHub. Paste a fine-grained personal access token with Issues: read & write on the repos you'll use, and set a default repository (owner/repo).
2. Add the webhook — copy the shown Payload URL and secret into your repo (Settings → Webhooks), content type application/json, and subscribe to Issues, Deployment statuses, and Releases.
3. Flow — close the linked issue, then a successful production deployment_status (or a published Release) resolves the incident.

Every inbound GitHub request is verified with its X-Hub-Signature-256 HMAC signature.

Jira

1. Connect — Team → Integrations → Jira. Enter your Atlassian account email, site URL (https://your-team.atlassian.net), an API token, and a default project key.
2. Add the webhook — in Jira: Settings → System → Webhooks → Create, using the shown URL (it carries a secret token). Subscribe to Issue: updated and Version: released.
3. Flow — move the linked issue to a Done status, then release its fix version to resolve the incident.

The site URL must be a public HTTPS host; the webhook is authenticated by the shared token in its URL.

Release webhook

If your pipeline doesn't fit the GitHub/Jira webhooks, tell us about a release directly. This is the most CI-agnostic option and works on its own.

curl -X POST https://error.page/api/v2/releases \
  -H "X-Project-Key: ep_live_…" \
  -H "X-Secret-Key: eps_…" \
  -H "Content-Type: application/json" \
  -d '{
        "version": "1.4.2",
        "issues": ["#123", "PROJ-45", "https://github.com/acme/app/issues/123"],
        "incident_group_ids": ["<fingerprint>"]
      }'

• Auth — the project secret key (X-Secret-Key), never the public key. A release must not be spoofable.
• issues — any linked issue references shipped in this release. Matched by bare key, #number, owner/repo#number, or full URL.
• incident_group_ids — resolve incidents directly by their fingerprint, no linked issue required.
• Response — { "incidents_resolved": n, "users_notified": m, "version": "1.4.2" }.

Every matched incident is resolved and its opted-in users are notified, with the version included in the incident.resolved webhook payload.

Permissions & billing

Connecting integrations and creating/linking issues require an owner or admin on a Business (or Enterprise) organization. See Teams for roles.