Airbrake integration

What it does

The Airbrake integration lets your agency run a client's error triage from inside TaskJuice. Connect a client's Airbrake project once and you can list error groups for a release, fetch the details of a single group, mark a group resolved, and list deploys to correlate regressions with releases — feeding an error's details into a Slack alert, a ticket, or a client report.

Muting and unmuting a group are not yet exposed, so those stay in the Airbrake dashboard for now.

Connect an Airbrake account

1. Open your workspace in TaskJuice and navigate to Connections.
2. Choose Airbrake and click Connect.
3. In Airbrake, open the user-edit page (https://airbrake.io/users/edit) and copy your user key. The key authenticates every v4 API request as a Bearer token.
4. Copy the numeric project ID from the URL of the project's dashboard (https://airbrake.io/projects/<id>) and paste it into the connection form alongside the user key.

See the Airbrake API docs for the full key flow and per-project scoping.

Triggers

• airbrake/notice-received fires when Airbrake reports an error group — a new error, or a resolved error that re-occurs. To wire it up: publish the workflow, copy the trigger's ingress URL from the trigger panel, and paste it into the Airbrake project's WebHooks integration (Project settings → Integrations → WebHooks). Airbrake's form accepts only a URL — deliveries are unsigned, and the tenant-scoped ingress URL itself is the credential, so treat that URL as a secret.

Actions

• airbrake/list-groups lists error groups for the connected project, with optional resolution and environment filters and page-based pagination.
• airbrake/get-group fetches a single error group by ID, including occurrence counts and aggregate context.
• airbrake/resolve-group marks an error group resolved — close out a fixed error from the same workflow that reported it.
• airbrake/list-deploys lists deploys recorded against the project, useful for correlating regressions with releases.

airbrake/add-note is deprecated and cannot be added to new workflows. It was authored against a route that does not answer, so it never worked. Workflows that already reference it keep resolving, but the step will fail at runtime — replace it.

Known limitations

• Airbrake's REST API enforces a per-key rate limit. When the budget is exhausted Airbrake returns a 429 status, which TaskJuice surfaces as a retryable error so downstream resilience policies can back off.
• User keys are scoped to the user, not the project. A user without project access will fail with 403 on every call. Re-issue the key from an account with project access and reconnect.
• Airbrake's webhook integration ships unsigned and its configuration form accepts only a URL — there is no field for a custom header or secret. The tenant-scoped ingress URL is therefore the only delivery credential: rotate the workflow's ingress URL if it ever leaks.
• The notice envelope shape varies slightly across Airbrake-Ruby, Airbrake-Node, and Airbrake-Python notifier versions. Workflows that read deep fields should defensively check for nulls before referencing them.