Pipeline Events
Pipeline Events is the audit trail surface for Colony Cloud. Route: /dashboard/pipeline-events
It presents a chronological stream of structured events emitted by the Colony pipeline — every state transition, agent decision, LLM invocation, and system signal recorded as an immutable entry. Use Pipeline Events to audit what happened, debug a stuck issue, or verify that a self-healing action fired.
Event stream
Section titled “Event stream”Pipeline Events fetches from GET /pipeline/events with offset-based pagination. The stream covers all event types across the org, filtered by the controls described below.
Event types
Section titled “Event types”Colony emits eight event types. All are visible in the event-type dropdown filter.
| Event type | What it records |
|---|---|
state_transition | A pipeline issue moved from one state to another (e.g. planning → in-review). |
agent_decision | An agent produced a routing decision — which next step to take, which tool to invoke, or whether to escalate. |
claude_execution | A Claude LLM invocation completed — model, turn count, and token spend recorded. |
workspace_lifecycle | A Worker workspace was created, attached to a task, or torn down. |
error | An unhandled error occurred in the pipeline — includes the error message and the agent or Worker that emitted it. |
circuit_breaker | The circuit breaker opened or closed on a downstream dependency (GitHub API, LLM provider, etc.). |
cost_alert | A cost threshold was crossed — daily, per-issue, or per-run cap triggered a warning or hard stop. |
self_healing | The self-healing subsystem detected and acted on a pipeline anomaly automatically. |
Filters
Section titled “Filters”Two controls narrow the event stream:
- Event type dropdown — select a single event type to show only events of that kind. Defaults to All types.
- Repository filter — the global repository selector in the sidebar applies to Pipeline Events. Select a specific repository to see only events for that repo.
Changing either filter resets the page offset back to the first page.
Table columns
Section titled “Table columns”| Column | What it shows |
|---|---|
| Time | Local timestamp of the event, formatted to the second. |
| Event type | The event type as a coloured badge. |
| Repository | The owner/repo that the event is associated with. Links to the repository page. |
| Issue | The linked issue number when the event is associated with a specific pipeline issue. Shows — for org-level events. |
| Agent | The name of the agent or Worker that emitted the event. |
Pagination
Section titled “Pagination”The event table shows 50 events per page. When there are more than 50 results for the active filters, Previous and Next buttons appear below the table with a count of the current range (e.g. “Showing 1–50 of 312”).
Pagination is offset-based — navigating to the next page fetches the next 50 events from the API.
Auditing and troubleshooting
Section titled “Auditing and troubleshooting”Pipeline Events is the starting point for any investigation into unexpected pipeline behaviour.
To trace a stuck issue: filter by the repository and look for state_transition events for the issue number. The sequence of transitions shows exactly where the issue stalled and when.
To investigate a cost spike: filter by cost_alert and claude_execution to see which agent invocations were most expensive and when cost thresholds were breached.
To confirm self-healing fired: filter by self_healing to see whether the anomaly was automatically resolved, and by error to see the underlying error that triggered it.
To audit a circuit-breaker open: filter by circuit_breaker to see when a downstream service became unavailable and when it recovered.