Simple dashboards to monitor your content pipeline
How to track ideas, drafts, translations, builds, and publications without turning your editorial operation into an overcomplicated dashboard.
A content pipeline does not break all at once. It starts breaking silently.
An idea remains stuck without an owner. A draft is created without sources. A translation is generated, but not reviewed. A post is published in Portuguese, but the English and Spanish versions are forgotten. A deployment fails, nobody sees it, and the site keeps looking normal until someone realizes the latest publication never went live.
That is why simple dashboards matter. Not to create another pretty screen, but to see bottlenecks before they become operational debt.
What editorial health means
Editorial health is not publishing every day. It is also not having a huge list of ideas.
For me, a healthy pipeline is one where every item has a clear status, a visible next step, and a low risk of being forgotten.
This applies to a personal blog and to a network of sites. The difference is that, in a network, mistakes scale faster. If the process depends on memory, open tabs, and scattered messages, it works while volume is small. Then it becomes noise.
A healthy operation answers simple questions:
- how many ideas are waiting for triage?
- how many texts are in review?
- which posts have a PT version but still lack EN and ES?
- which builds failed?
- which sources need checking?
- which pieces are ready but not yet published?
If I cannot answer this in a few minutes, the problem is not lack of productivity. It is lack of visibility.
Metrics that matter
A common mistake is starting with the ideal dashboard: charts, filters, colors, rankings, and complex screens. It is almost always too early.
I would start with operational metrics, not vanity metrics.
The first ones would be:
- Ideas by status: suggested, approved, in production, in review, published, rejected.
- Time stuck per step: how many days an item has gone without status change.
- Language coverage: PT published, EN pending, ES pending.
- Automation failures: n8n executions with errors.
- Build/deploy failures: commits that did not reach the site.
- Posts without enough sources: technical content without a minimum reference set.
- Posts without internal relationships: orphan pages inside the blog itself.
These metrics are not meant to impress. They are meant to decide the next action.
A good editorial dashboard should point to work, not just show numbers.
A simple panel
In this lab architecture, the most pragmatic panel starts in Baserow.
It can already store ideas, status, language, priority, source, keywords, final URL, and notes. With a few well-designed views, Baserow becomes a simple editorial cockpit:
- a view for triage;
- a view for texts in review;
- a view for pending translations;
- a view for ready publications;
- a view for errors or blockers;
- a view per project or domain.
n8n comes in as the engine. It can update status, register logs, save the latest execution date, store the GitHub API response, and mark whether the deploy was triggered.
Astro remains the public layer. It does not need to know about operational mess. It receives valid files and generates static pages.
That separation matters: the panel shows the operation; the public site delivers content.
Alerts before pretty dashboards
Before spending energy on dashboard layout, I would create simple alerts.
Some examples:
- an approved idea with no draft after more than 7 days;
- a PT post published with no translation after 5 days;
- an n8n workflow with an error;
- a Cloudflare Pages build failure;
- a technical post with no sources;
- content marked as ready but still with
draft: true; - duplicated or missing canonical.
The right alert reduces the need to stare at a panel.
A dashboard is good for periodic review. An alert is good for exceptions. Mixing the two usually creates operational anxiety: the person starts monitoring a screen instead of improving the process.
Review routine
A dashboard only works if there is a routine behind it.
My suggestion for a lean operation would be:
- Monday: review new ideas and approve priorities;
- Wednesday: check texts in production and pending translations;
- Friday: review publications, internal links, sources, and failures;
- once a month: clean rejected ideas and revisit editorial pillars.
None of this needs to be complex. The goal is to prevent the pipeline from becoming a warehouse of intentions.
In the end, a good dashboard is not the one that shows everything. It is the one that shows enough for you to make the next decision clearly.
For a Systems Builder, that is the difference between simply producing content and building an editorial operation that can grow.