Dashboards · telemetry · observability
Monitoring dashboards and software
I design interfaces and data pipelines that make systems, consumption, resources and technical signals understandable without separating the UI from the reliability of the data behind it.
Typical problem
A dashboard is useful only when the data behind it is coherent, current and interpretable
Charts and KPIs do not solve monitoring on their own. The system needs explicit data origins, granularity, live-state semantics, history, quality rules, fallbacks and a clear definition of what genuinely deserves attention.
Data is scattered or hard to read
Measurements, logs or states already exist but are distributed across tools or require manual processing before they become useful.
Live and historical views disagree
Current values, aggregates and time series need clear semantics so comparisons and trends do not become misleading.
Too much information, too little priority
A technical UI should distinguish normal state, margin, anomaly and context instead of promoting every available value to a primary metric.
Use cases
Monitoring designed around decisions
The interface may be a web dashboard, desktop application or embedded surface; the starting point remains what a person needs to understand and do.
Live telemetry
Current state, electrical or environmental measurements, system resources, connections and operational indicators with controlled refresh behaviour.
Time series and comparisons
History over coherent intervals, rollups, comparable periods and drill-down when the raw data is actually useful.
KPIs and operating margins
Summary indicators connected to thresholds, capacity, consumption, cost or other limits with an explicit operational meaning.
Alerts and diagnostics
Selective signals for anomalous conditions, accompanied by enough context to understand whether and how to act.
Approach
Design the meaning of the data before the visualization
Dashboard and backend are treated as one information contract: every value needs an origin, unit, time window and defined behaviour when data is missing.
- 01
Define questions and decisions
Identify what users need to know, how frequently they need it and what action can follow from an indicator or anomaly.
- 02
Build a coherent data pipeline
Acquisition, normalization, storage, aggregation and APIs are aligned with the semantics the interface needs to represent.
- 03
Verify readability under real conditions
Test empty states, latency, missing data, scales, responsive behaviour and realistic loads so the dashboard is not correct only with ideal datasets.
Possible outputs
From raw data to an operational surface
Work can start from an existing data source or include the pipeline required to make it reliable and queryable.
Engineering evidence
Monitoring already implemented on real data and runtimes
The evidence spans both an end-to-end telemetry path and a focused Linux utility for machine state.
Home Energy Meter
Live dashboard, consumption, technical charts, rollups, F1/F2/F3 bands, loads, costs and forecasting built over real electrical measurements and edge persistence.
Open the case studySentinelux
Open-source Linux monitor for CPU, RAM, swap and temperatures from the system tray, with configurable thresholds and alerts; available as source-only pre-alpha.
Open SentineluxOriqo
Multi-repository product with web surface, authoritative backend and Integrated Admin Center: evidence of operational interfaces tied to explicit backend contracts.
View the architectureNew monitoring system
Tell me which decisions need to become faster or less ambiguous
In the brief, include existing data sources, update frequency, dashboard users and the conditions that need to stand out immediately.