A content operations dashboard exists to answer three questions before you have finished your first coffee: what is scheduled to go out, what is waiting on review, and what has already published. If your team has to open five tabs and ask two people to find those answers, the dashboard is not doing its job. The point of a dashboard is to compress the state of every Content Item, Project, and Client into a glance — so the people running the pipeline spend their attention on the content, not on hunting for status.

This article breaks down what a good content operations dashboard should actually show, the difference between a signal and noise, and how the moving parts — status breakdowns, the pipeline, project health, and publish and deploy visibility — fit together. The goal is a single screen that tells the truth about where work stands and what needs a person right now.

The three questions a dashboard must answer at a glance

Everything else on the screen is supporting detail. If a dashboard cannot answer these three questions in a few seconds, it has failed its core job.

  1. What is scheduled? Which Content Items are approved and queued to commit, and when. This is your forward view — the calendar of what the website will say next.
  2. What needs review? Which items are sitting in the Review Queue waiting on a Client Reviewer or an internal editor. This is your bottleneck view — the work that has stopped moving and needs a decision.
  3. What published? Which items committed to the repository recently, with their commit and deployment status. This is your rear view — confirmation that the website actually changed.

Notice the shape: future, stuck, and done. A reader should be able to map any item on the dashboard to one of those three buckets without thinking. When all three are visible together, the daily standup question — "where are we?" — answers itself.

Tip

If your team's first action every morning is to message someone asking "did that post go live?", that question belongs on the dashboard as a published-recently panel, not in a chat thread.

Status breakdowns: where work actually is

A raw list of content is not a dashboard. The value comes from grouping items by status so the distribution is visible at a glance. In a Git-backed workflow, every Content Item carries an explicit state, and the dashboard should summarize those states as counts you can scan.

A useful status breakdown distinguishes at least:

  • Draft — being written or edited, private in the app, not yet sent anywhere.
  • In review — assigned to a reviewer and waiting on Approve or Request Changes.
  • Changes requested — kicked back with comments; the ball is in the team's court.
  • Approved — signed off and cleared to publish.
  • Scheduled — approved and queued to commit at a chosen time.
  • Published — committed to the connected repository on the configured branch.

The breakdown matters because a pile-up in any one column is a story. Twenty items stuck in "in review" means a reviewer is overloaded or unresponsive. A swelling "changes requested" count means the brief or the writing needs attention upstream. A healthy pipeline keeps work flowing left to right rather than collecting in a single bucket. For more on how those states are defined across content types, see Posts, Pages, and Custom Content Types.

The pipeline view: from draft to deployed

Status counts tell you the totals; the pipeline tells you the motion. A content operations dashboard should show the path a piece travels and where the friction sits along it.

The stages that matter

A typical Acrosite pipeline runs: draft is written, it enters the Review Queue, a Client Reviewer or internal editor approves or requests changes, the approved item is either published immediately or held for Scheduled publishing, the commit lands in the connected GitHub repository, and a configured deployment trigger rebuilds the site.

A good pipeline view answers questions like:

  • How many items are between "approved" and "published" — work that is done but not yet live?
  • Is anything scheduled for today or this week that still needs a final check?
  • Where do items spend the most time? If everything waits three days in review, that stage is your constraint.

When the pipeline is visible, you stop discovering problems at the worst possible moment — the morning a client expected something live and it never committed.

Project and client health at a glance

A single content team rarely runs a single website. Inside a Workspace you have multiple Projects, each mapped to a Client website and repository, and the dashboard has to stay legible across all of them.

Project health is a rollup. For each Project, a strong dashboard surfaces a few honest signals:

  • Overdue or at-risk scheduled items — anything queued for a date that has passed, or due soon with no reviewer sign-off.
  • Stalled reviews — items that have been waiting on a Client Reviewer longer than your team's norm.
  • Recent publish failures — any publish attempt that did not complete cleanly and may need a retry.
  • Last successful publish — a simple recency marker per Project so a quiet website does not silently fall behind.

The trap here is showing every Project at equal volume. A dashboard that lists thirty Projects with identical green checkmarks is noise. A dashboard that quietly elevates the two Projects with a stalled review or a failed publish is signal. If you manage many client sites, the patterns in managing multiple client websites from one workspace are worth reading alongside this.

Publish and deployment visibility

Publishing is the moment content becomes a commit, and deployment is the moment that commit becomes a live page. These are two different events, and a content operations dashboard should treat them as such.

Reading Publish Logs without the noise

Publish Logs record each publish attempt's steps — content validated, committed to GitHub, commit SHA saved, deployment triggered — without ever exposing tokens, hook URLs, or raw provider payloads. On the dashboard, you do not want the full log for every item; you want the exceptions. Surface the failed and retried attempts, and let the successful ones collapse into a count. A failed publish that can be safely retried is the single most actionable thing a dashboard can show, because it is a live task, not a historical record. The deeper mechanics live in Publish Logs and failed publishing.

Deployment visibility as the final confirmation

A commit landing in the repository is not the same as a page being live. After the commit, a configured deployment trigger profile tells the hosting provider to rebuild — manually or automatically — and Deployment Logs record the results. Deployment visibility on the dashboard closes the loop: it confirms that the change your team approved actually reached the audience. Without it, "published" is a half-truth, because the commit might be sitting in a branch that has not rebuilt yet.

Signal versus noise: what good looks like

The hardest part of a content operations dashboard is restraint. Every metric you add competes for attention with the three questions that actually matter. A few principles separate a dashboard people trust from one they ignore:

  • Default to exceptions. Show what needs a human — stalled reviews, failed publishes, overdue schedules — and let healthy work stay quiet.
  • Counts over lists. A number you can scan beats a list you have to read. Lists belong one click deeper.
  • Recency, not history. The dashboard is a live view. Archive the full audit trail to the logs, where it belongs.
  • One screen, no scrolling for the basics. If the three core questions require scrolling, the layout is wrong.
  • Every number links somewhere. A count of seven items in review should be a door into those seven items, not a dead end.

A quick checklist for evaluating your own dashboard:

  1. Can a new team member answer "what is scheduled, what needs review, what published" in under thirty seconds?
  2. Does a failed publish or a stalled review visibly stand out, or does it blend into green?
  3. Can you reach the underlying Content Item from any number on the screen?
  4. Is anything shown that you have never once acted on? If so, remove it.

If your dashboard passes those four, it is earning its place. To see how these pieces connect across the wider product, the features overview is a good map, and the Content Calendar covers the scheduling view in depth.

Frequently asked questions

A content calendar is a forward-looking, date-based view of what is scheduled to publish. A content operations dashboard is broader: it combines the calendar with status breakdowns, the review pipeline, project health, and publish and deployment results so you can see the whole state of work, not just upcoming dates.
Fewer than you think. Prioritize the three core questions — scheduled, needs review, published — and surface exceptions like failed publishes or stalled reviews. Anything you have never acted on is a candidate for removal, because every extra number competes with the signals that matter.
No. In Acrosite, Client Reviewers are invited per Project and see only the content assigned to them through the Review Queue. They have no access to the internal operations view, billing, Workspace settings, or GitHub. The full dashboard is for your internal Team Members.
Published means the Content Item was committed to your connected GitHub repository on the configured branch, recorded in Publish Logs with its commit SHA. Deployed means a configured deployment trigger rebuilt the hosting provider, recorded in Deployment Logs. Deployment visibility confirms the commit actually became a live page.
Because a failed publish is a live, actionable task rather than a historical fact. It usually means an approved piece of content did not reach the website, and where it is safe, it can be retried directly. Surfacing it prominently prevents a silent gap between what your team approved and what visitors actually see.