Current Status

The Current Status tab (/repos/<owner>/<name>) is the live pipeline view for a repository. Its tab tooltip reads: “Live view of this repository’s pipeline — active issues, running agents, and recent events.” Issue data is loaded from GET /api/repos/<owner>/<name>/issues and refreshed on each page visit.

Issues by state

Active issues are grouped into collapsible sections, one per pipeline state. Sections are ordered by enumerateWorkflowStates — the canonical workflow traversal order — so states appear in the same sequence as the pipeline flow (new → analyzing → planning → ready-for-dev → in-review → done), with any extra states appended after.

Each section header shows a state badge (color-coded by the workflow snapshot variant) and the total issue count for that state. Click the header to expand or collapse the section.

Within an expanded section:

• Issues are shown as pill chips (issue number + title for non-done sections with fewer than 10 issues; the done section and any section with 10 or more issues show the number only).
• Each chip links to the issue detail page at /repos/<owner>/<name>/issues/<number>.
• When the displayed count is less than the total for that state, a Show more button loads the next 20 issues from GET /api/repos/<owner>/<name>/issues?state=<state>&limit=<n>.

Terminal states (done and any paused state defined in the workflow snapshot) start collapsed. All other states start expanded.

Completions histogram

The done section includes a Completions histogram when expanded. The chart renders completed-issue counts over a 90-day lookback window using GET /api/repos/<owner>/<name>/issues/histogram.

Three granularity buttons control the aggregation bucket:

Button	Aggregation
Day	One bar per calendar day
Week	One bar per calendar week
Month	One bar per calendar month

The default granularity is Week. Switching granularity re-fetches the histogram immediately. The chart is lazy-loaded — the first fetch fires on the first time the done section is expanded.

Actions

Two action buttons appear in the top-right of the tab:

Action	Who sees it	What it does
File issue	All users	Opens the File Issue dialog to create a new GitHub issue that Colony will pick up and process through the pipeline.
Import plan	Admins and owners only	Opens the Import Plan dialog to bulk-import a pre-structured plan as pipeline issues.

Both buttons appear whether or not there are active issues (including the empty state).

Subscription-auth limit notice

When a repository’s authMode is oauth-token (subscription auth), a notice card appears above the issue list:

1-Worker limit (subscription auth)

This indicates that the repository is running under a subscription authentication mode that restricts it to a single active Worker. The notice does not block any action — it is informational only.

Empty state

When no issues are active in the pipeline, the tab renders an explanatory card:

No active issues in the pipeline. Issues flow through Colony’s pipeline automatically: new → analyzing → planning → ready-for-dev → in-review → done. Create a GitHub issue with the Colony label to start, or switch Intake Mode to “All issues” in repo settings.

A Repo settings button links to /repos/<owner>/<name>/settings.

A secondary tip card notes that a .colony/conventions.md file in the repository can be used to customize agent behavior.

The File issue and Import plan buttons are also present in the empty state, so issues can be created even before any pipeline activity has occurred.

---

Weekly reliability

Note

The weekly reliability metrics described below do not appear on the Current Status tab. They are rendered in the weekly-reliability card on the Digest Notifications settings page (/settings/digest-notifications), sourced from GET /pipeline/weekly-reliability. They are documented here because the Repository Workspace index links to this page as a starting point for per-repo reliability information.

The weekly reliability card reports seven per-repo metrics over a 7-day rolling window. Full definitions and calculation methods are in the Metrics reference → Weekly Reliability.

Metric	Definition
Completed	Count of distinct issues that reached done state in the 7-day window for this repository.
Recovered	Count of issues that entered a failure or blocked state and subsequently reached completion in the 7-day window. A high recovered count relative to completed count signals that many issues hit blockers before finishing.
Cycle p50	Median (p50) cycle time from first pipeline transition to issue completion, measured in seconds over the 7-day window. Null when no issues completed.
Cycle p90	Ninety-fifth-percentile (p90) cycle time from first pipeline transition to issue completion, measured in seconds over the 7-day window. A large gap between p50 and p90 indicates high tail latency. Null when no issues completed.
Dead letters	Count of dead-letter events — tasks that exhausted all retry attempts without resolution — generated for this repository in the 7-day window. Non-zero requires manual operator triage.
Retry budget	Retry budget consumption: tasksRetried (retry-attempt row count) and totalRetriesConsumed (cumulative attempt-index sum) across all work tasks in the 7-day window.
Fleet degraded time	Total seconds the fleet spent in degraded mode — at least one Worker reporting a degraded state — during the 7-day window. Fleet-wide; not scoped to this repository alone.

To receive these metrics on a schedule, configure a Digest Notifications delivery.