Skip to content

Docs / Dashboard screens

Dashboard screens

The product, screen by screen, in the order work moves: Overview, Plans, Fleet, CI runs, Pending actions, Blockers and Audit log.

Sign in at app.developerz.ai. Every account screen lives under your organization, at /org/<your-org>/…, and the sidebar groups them by the job they serve: Orient, Watch, Decide, Prove & configure and Settings.

This page walks the screens in the order work moves through them: planned, run on your boxes, checked by CI, held for a person where your policy asks, and recorded. Each section names the path, what the screen shows, and what you can do there.

Overview

/org/<your-org>/ · sidebar group Orient, labelled Home.

The first screen after sign-in. It shows:

  • Four tiles: pull requests merged in the last 24 hours, open pull requests across your repositories, how many boxes are working, and your token spend per hour. A tile whose source cannot be read shows a dash, never a made-up zero.
  • Fleet: your enabled repositories, each with its current task, status and last update.
  • Audit feed: the latest agent sessions, updated live while the page is open.
  • Pending actions: the head of the queue of pull requests waiting on your decision, with the same Approve and Skip buttons as the full Pending actions screen.

While setup is unfinished, a banner points you at the next step. View all on each panel opens the full screen behind it.

Plans

/org/<your-org>/fleet/plans · group Watch. Also reached from the Plans button on Fleet.

Every plan a scout authored for your account, newest activity first, 100 to a page. Each card shows the plan's lead slice, its repository, how many of its slices have merged out of the total, and how many slices are stalled (slices that can no longer merge, for example because their task failed or their pull request was closed unmerged). Plans that you or a teammate started yourselves are listed separately, above the full list.

What you can do:

  • Start a plan. Pick an enabled repository and write the ask the way you would brief a person. A scout session on one of your boxes reads the repository and authors the plan: slices first, then the tasks that ship them. The screen tells you the scout task was dispatched; the plan itself appears once the scout has written it, which takes minutes, not seconds.
  • Open a plan to see its slices in dependency order, each with its task and pull request.
  • Stop epic on an open plan. Every unfinished slice is stopped and any box working on one is interrupted; slices that already finished are untouched, and a review slice that is already running keeps running.

Fleet

/org/<your-org>/fleet · group Watch.

Your boxes and the work queued for them. It shows:

  • A status band: workers, online, starting up, needing attention, able to take coding work, and the spend in the current window.
  • An alert for any box that never reported in or stopped reporting. Queued work is routed to the healthy boxes meanwhile.
  • Box budget: how many boxes your plan lets you enroll, and how many are in use.
  • Workers: one card per box with its last heartbeat and its runner version.
  • Builds in the fleet: which runner versions your boxes are running.
  • Task queue: the newest tasks, updated live.

What you can do:

  • Add a box to enroll a new machine.
  • Manage a box: change what work it may claim, or Drain it, which re-queues its in-flight work for the rest of the fleet. A drained box stays enrolled.
  • Revoke a box, which removes it from the fleet.
  • Roll out an update to point your boxes at a runner build. The rollout is staged (canary, soak, then waves), so this starts it and it finishes over minutes to hours.
  • New task to dispatch work, and Stop on a task to interrupt it. A stopped task is marked cancelled and nothing re-queues it.

Opening a run from the queue shows its timeline at /org/<your-org>/fleet/runs/<run-id>: the run's events, streamed live while it is running.

CI runs

/org/<your-org>/ci · group Watch, labelled CI runs.

The GitHub Actions jobs routed to your own boxes, newest first, updated live. The screen is read-only: a run starts when GitHub sends a job carrying one of your runner labels, so you start one by changing runs-on: in a workflow (see Self-hosted CI), not from here.

View full log opens a short-lived link to a job's archived log. Logs are kept for three days; after that the button reports that no log is available.

Pending actions

/org/<your-org>/pending · group Decide, labelled Pending.

The pull requests your policy holds for a human decision before anything merges them, across every repository, longest-waiting first. A pull request lands here when:

  • it matches a category in escalate.ask_before_acting, such as a first-time contributor or a pull request over pr.large_threshold_lines. On a repository that auto-merges, a pull request opened by the platform's own App or by Dependabot or Renovate is held only by a category your maintainer.yml writes, never by the default list (see Dependency bots);
  • its target branch or changed paths match pr.human_merge;
  • you approved it, and new commits arrived on it before it merged;
  • an agent session stopped and asked for a merge decision.

Each row shows the category, the pull request, the drafted action (with its author and CI state), and how long it has waited. What you can do:

  • Approve to let the bot merge it. The approval is for the exact head commit the row showed: if someone pushed since, the decision is refused, and you decide again on the new head.
  • Skip to decline the drafted action.

There is no "approve all". Each decision is its own call, and every merge still goes through the same merge gate. The same decisions are available over MCP (pr approve_pending, pr skip_pending) and the REST API; see Escalations for what raises them.

Blockers

/org/<your-org>/blockers · group Decide.

The questions the platform is waiting on a person for, oldest first, because the oldest unanswered one is the most overdue. Each blocker shows where it came from: its repository, and the run, task and box behind it when there is one. Not every blocker comes from a run: a repository whose tags include no stable X.Y.Z version pauses its releases with one, and no run is behind it. A notification about one blocker opens this screen on that blocker alone.

What you can do:

  • Send answer. Give the location of what is missing (for example, "NPM_TOKEN is in 1Password under Build"), never a secret itself. The answer is stored on the blocker and audited, and it cannot be unsent. Answering closes the blocker and files a new ask that carries both the question and your answer. Triage decides that ask: it may become new work, be linked to work already running, or be dropped. The run that asked, if there was one, does not resume. The exception is a blocker holding a task whose retries were spent on a fault in the box's environment: answering it runs that task again with fresh attempts, your answer as its guidance, and files nothing for triage.
  • Withdraw a question that no longer needs an answer. The record stays, marked withdrawn, and nothing is dispatched.
  • Show answered, withdrawn and expired blockers alongside the open ones.

Audit log

/org/<your-org>/audit · group Prove & configure, labelled Audit.

Every agent action across your account that is shown to maintainers, newest first. Each row names the tool or event, the repository and the time. Load more pages further back.

Opening a row shows that session's timeline at /org/<your-org>/audit/<session-id>:

  • a header with the repository, what triggered the session, its outcome, the model, and a link to the issue or pull request on GitHub;
  • every event of the session, streamed live while it runs, with its input and output, a marker on anything redacted, and Copy link to this event for a permalink;
  • filters by tool and by outcome;
  • Export JSONL to download the whole session, one event per line;
  • Replay with new policy to re-decide the session's policy refusals and escalations against a candidate maintainer.yml. It executes nothing and stores nothing. See Policy replay.

The other screens

The sidebar also carries Repos (per repository: issues, policy, pending decisions, reviews, audit, knowledge base, secrets and settings), Dashboards (your own realtime boards), Digests, Agents, Terminal, Artifacts, Keys, Notifications, Billing, and the account settings under Settings.