跳到正文
FunCoding

搜索

搜索文档、文章、Skill 和 MCP

Factory dashboard

Track work items, inspect runs, read factory metrics, and manage agents, automations, webhooks, and settings from the factory dashboard.

The factory dashboard is the web app for operating a single factory. Open the <a href=https://platform.warp.dev>Warp Factories web app, then select a factory to track its work, inspect its runs and pull requests, and manage its agents, automations, and settings.

"Factory dashboard" names the whole surface. Dashboard, in bold, is one page inside it: the metrics page you land on when you open a factory.

Getting oriented

Select a factory in the sidebar to open its pages. Runs, MCPs and apps, Secrets, and Integrations sit above the factory list and cover your whole team, not a single factory. Inbox sits there too, but it's neither team-wide nor per-factory: there's a single global Inbox page, and it shows only the items waiting on you personally, across every factory you have access to. Everything else on this page is scoped to the factory you select.

A factory opens on its Dashboard page, covered next. Factory definition appears only on Warp-managed factories, since a factory whose definition lives in your own repository is edited there instead.

Read metrics on the Dashboard page

Dashboard is the factory's landing page. It summarizes the factory over a date range you choose:

  • Autonomy - The share of the factory's merged PRs that needed no human code push before merging. Opening the PR counts as a push, so a human-authored PR that a factory run later revised doesn't count as autonomous; comments, reviews, requested changes, and the merge itself don't count as a push.
  • PR cycle time - The median time the factory's merged PRs took from run kickoff through PR, first review, and merge, with an independent median for each stage - the stage medians don't sum to the headline.
  • Cost per PR - The median cost of PRs opened in the range. When a single run produces more than one PR, its cost splits evenly across them. Treat it as a lower-bound estimate: it can miss some run usage and does not match billing. See Measure and improve a factory for its limitations.

The page also charts opened versus merged PRs and a breakdown of runs, and the Cost per PR card expands to list the most expensive PRs in the range. When Scorers are set up, Scorer cards summarize recent classification results.

![The Dashboard page showing a Cost per PR chart broken down by compute, platform, and inference cost, plus two example Scorer cards.](/official-assets/warp/src/assets/factories/factory-dashboard-metrics.webp)
Cost per PR and example Scorer cards on the Dashboard page.

Find what needs you in Inbox

Inbox collects the questions, spec approvals, and pull request reviews waiting on you across every factory, so you don't have to check each factory's Runs page for stalled work. See the factory inbox page for the kinds of items it shows and how to resolve them.

Inspect runs

A run is a single agent execution. A single request can span several runs as different agents pick it up, and related runs group under their parent in the list. The team-level Runs page lists every run you have access to; a factory's Runs page lists only runs from that factory's agents.

Click New on a factory's Runs page to send a prompt to the factory's foreman agent. Open a run to see its timeline and cost, plus a Sub-agents tab for child runs when the agent used multi-agent orchestration. From there you can view the agent's full session, stop or score the run, or turn it into a benchmark task.

Run pages don't include a chat input, but you can still steer a run: View session opens its shared agent session, where you follow the agent in real time and send follow-up instructions while the run's sandbox is active. After it shuts down, the same button opens the conversation transcript.

Manage agents and automations

Agents lists the factory's agents. Create agents and edit their instructions, model or harness, runner, host, secrets, and MCP servers. Automations defines the triggers that start runs: a schedule (including custom cron expressions), a GitHub, Linear, Slack, or Jira event, or a delivery to a custom webhook. Webhooks is a tab within Automations that lists the factory's custom webhooks, where you create them, copy their URLs, rotate secrets, and read the delivery log.

The automation editor doesn't change execution settings; an automation only overrides them through execution overrides in the definition files. When the factory's definition lives in an external repository, Agents, Automations, and Scorers are read-only; make changes there through pull requests.

Edit definitions in the Factory definition tab

Factory definition is the factory dashboard's view of the definition files that definitions as code describes in full. Where the definition lives decides what you get:

  • Warp-managed - Browse and edit the definition files. Saving validates the definition and commits all changes together.
  • Managed in GitHub - The tab doesn't appear. Edit the definition through pull requests in your repository, and Settings links back to it.
  • Live-managed - The factory is managed through the API, so there are no definition files to browse.

When an agent proposes a change to a Warp-managed definition, a spec review for the branch appears in your inbox. Open it to comment on the diff, use Request changes to send feedback back to the agent, or Approve & merge.

Score and benchmark

Scorers is where you create Scorers and read their results. Self-improvement lists the pull requests the self-improvement flow opens after analyzing runs your Scorers mark as failing, and Benchmarks compares model and runner configurations against a fixed set of tasks. See Configuring Scorers, Configuring and reviewing Self-improvement, and benchmarking factory agent configurations for what each one is and how to use it.

Change factory settings

Settings holds the configuration the factory owns:

  • Identity - The factory's name, avatar, and Foreman name, the handle your team @-mentions.
  • Repositories - The repos the factory works in.
  • Pull request authorship - Whether pull requests are authored by the agent or the run creator (the definition's credentialStrategy).
  • Analysis model - The model Self-improvement uses to analyze failed runs.
  • Runners - The compute the factory's runs execute on. See factory runners to choose runner configuration or managed self-hosting to run factory work on your infrastructure.
  • Integrations - The integrations this factory can access.
  • Deletion - Deletes the factory. This cannot be undone.

For a file-managed factory, runners/*.yaml in the repository is the source of truth. Anything managed in an external repository is read-only in Settings.