Monitor
Industrial dashboards built for three different audiences
An operator, a plant head and a director need completely different views of the same data, and a single dashboard that tries to serve all three serves none of them. We design a set: the floor display that changes behaviour in the moment, the supervisor view that supports the shift, and the summary that answers the question a director actually asks.
The problem
The dashboard everyone stopped opening
It exists. It was expensive. It has forty-two tiles. Nobody has looked at it since the second week, because it answers questions nobody was asking and does not answer the one they were.
- 01
A dashboard exists but decisions are still made from a spreadsheet
- 02
Numbers on the dashboard disagree with numbers in the monthly report
- 03
It is unusable on a phone, which is where most people would actually check it
- 04
It shows what is happening but gives no indication of whether that is good or bad
- 05
Nobody can say what any given tile is supposed to prompt someone to do
What we build
Concrete deliverables
Nouns, not adjectives. This is what actually gets handed over.
- 01
Audience-specific views
Separate designs for the shop floor, the supervisor, the plant head and the group level — each showing only what that audience can act on.
- 02
Shop-floor displays
Large-format screens readable from a distance, showing current rate against target and current state, designed to change behaviour within the shift.
- 03
Mobile-first management views
Because the plant head checks production from a phone at 7am, not from a desktop.
- 04
Data model and semantics
One agreed definition per metric, documented, so the dashboard and the monthly report cannot disagree.
- 05
Alerting and escalation
Threshold and trend-based alerts delivered by the channel people actually read, with escalation when nobody responds.
- 06
Reports and exports
Scheduled shift and daily reports, plus exports and an API for whoever wants the raw numbers.
How it works
The technical path, step by step
Where the engineering decisions actually get made.
- 01
Establish the questions
We interview each audience for the questions they currently answer by asking someone. Those questions become the dashboard specification.
- 02
Agree the definitions
What counts as downtime, what counts as good output, when a shift starts. Ambiguity here is the single largest cause of dashboards being distrusted.
- 03
Design for the context
Distance and glance for the floor; density and drill-down for the supervisor; a handful of numbers with trend for management.
- 04
Build on live data
Wired to the actual data path — no manual imports, no nightly spreadsheet step anywhere in the chain.
- 05
Review after a month
We look at what is actually being opened. Tiles nobody uses get removed. This step is where a dashboard stops being decoration.
Protocols & technologies
Specifics, because vague answers cost you money later
Chosen per site according to what is installed, not according to what we would prefer to work with.
| Technology | Where it is used | Engineering note |
|---|---|---|
| Time-series database | Process and machine history | Designed with retention and downsampling policies rather than keeping everything at full resolution forever. |
| PostgreSQL / SQL Server | Transactional, batch and master data | Where relational structure and joins matter more than write throughput. |
| MQTT subscribe | Live values | Sub-second updates without polling the database. |
| REST / GraphQL API | Serving the dashboard and third parties | The same API serves your BI tool, so there is one version of the truth. |
| WebSockets / SSE | Live browser updates | Push rather than poll; the difference is visible on a floor display. |
| Grafana / custom application | Presentation layer | Grafana where it fits and your team will maintain it; a custom application where the interaction model matters. |
Brownfield
Dashboards on top of what you already have
A dashboard does not require replacing your systems. We routinely build on an existing SCADA historian, an existing PLC network, an existing ERP, or all three at once — reading from them through a controlled boundary rather than migrating anything.
Works with
- Existing SCADA historians as a data source
- Existing ERP and MES databases
- Machines connected through our own IIoT layer
- Manually entered data where automation is not yet justified
- A mix of all of the above, which is the usual case
Use cases
What people actually ask us for
Each one is a situation followed by the outcome it produces — not a feature list.
Live shop-floor target display
NowOperators find out they are behind at the end of the shift.
AfterRate against target visible continuously, so the shift can respond while it can still recover.
Morning production summary
NowThe plant head chases three people for numbers every morning.
AfterA summary that arrives before they wake up, on their phone.
Multi-plant comparison
NowSites report in different formats on different days.
AfterOne normalised view with a common definition set and drill-down to machine level.
Energy dashboard
NowEnergy is managed from a monthly bill.
AfterConsumption by machine, shift and unit produced, with anomalies flagged as they happen.
Quality and traceability view
NowTracing a batch means opening several systems.
AfterOne view assembling process, quality and genealogy for a given batch or serial number.
Implementation
How a project runs
Eight stages, each producing something you own. Full detail on the process page.
- 01
Discover
1–2 conversations
- 02
Audit
1–3 days on site
- 03
Design
1–2 weeks
- 04
Engineer
2–8 weeks per phase
- 05
Integrate
1–2 weeks
- 06
Deploy
Your shutdown window
- 07
Monitor
First 4–6 weeks
- 08
Optimise
Ongoing, if you want it
OEE and downtime reason capture
The half of machine monitoring that is usually done badly: capturing why a machine stopped, in under five seconds, in a way operators will actually keep doing.
Read the write-upQuestions
Industrial Dashboards — common questions
Grafana or a custom application?
Grafana is excellent for time-series exploration and for teams who will build their own panels — it is fast to deploy and free to start. A custom application is the right answer when the interaction model matters: guided drill-downs, reason-code entry, role-specific views, approvals, or anything a viewer does rather than just looks at. We often deliver both, with Grafana for engineering and a purpose-built app for operations.
Why not just use Power BI?
Power BI is strong for periodic business analysis and weak for live plant data — it is not designed for sub-minute refresh or for shop-floor display. A common arrangement is a real-time layer for operations and Power BI reading the same API for business reporting, which keeps one definition of every metric.
Can it work on a phone?
It has to. In our experience management checks production on a phone far more often than on a desktop, so the mobile view is designed first and the desktop view is the expansion of it, not the other way round.
How do we stop it becoming shelfware?
By designing from the questions people already ask rather than from the data that happens to be available, by keeping each view small, and by reviewing usage after a month and deleting what nobody opens. A dashboard with six tiles that are checked daily is worth more than one with forty that are not.
Who hosts it?
Your infrastructure — on-premises, your cloud account, or a hybrid where live data stays on site and summaries go to the cloud. We hand over the credentials, the schema and the deployment documentation.
What question can nobody answer today?
Tell us the question your team asks each other every morning. That is usually the first tile.