bvdart-health · Own project
One dashboard for four sites — bvdart-health
One dashboard that tracked four of my own sites on discoverability, speed, errors and cost, with one report every morning at eight on what needed attention. Built in June 2026 and since switched off.
No image is available for this project. The case describes how it worked and what it delivered.
- Project type
- Own project
- My role
- Monitoring design and development
- Status
- Completed · system retired
- Duration
- 2 days
- Team size
- 1
- The question
- Signals about speed, search visibility, costs and errors were scattered across multiple dashboards.
- The result
- One daily report collected issues across four sites. The system has since been retired.
The question
This is not a client project but a tool of my own. Keeping four sites running at once meant that the answers to simple questions (is this still being found, is it still fast, is it suddenly costing money, is something breaking) were spread across six dashboards from six providers. Then one message came in every morning at eight: this needs attention, or everything is within limits. While it ran, it more than once flagged a small mistake that would otherwise have cost money. The system has since been switched off.
Four sites, each with its own set of measurements at its own provider. Search visibility is in Search Console. Speed has to be measured. Costs are in four separate invoices with four different free tiers. Errors are somewhere else again.
As long as everything goes well, you don't look at any of it. That is exactly why you don't notice when it goes wrong: a free tier filling up, a page that got slower after a change, an error that has kept repeating since yesterday. None of these is dramatic. Together they are the things you only discover when someone else runs into them. What I needed was not more information, but less: one verdict a day.
Key issues
- Measurements spread over six dashboards from six different providers
- Usage that quietly builds up until it shows on the bill
- A slowdown after a change only gets noticed when a visitor complains
- No reason at all to check daily as long as everything seems fine
Constraints
- The monitoring must not depend on the systems it monitors
- Read-only access to the monitored environments
- Had to be usable within a few days, not after a project of weeks
Project background
This is my own work, and I say so up front. There is no satisfied client behind it; what it shows is how I work when nobody is watching, and what tools I build for myself when something bothers me too often.
My approach and decisions
The system must not go down with what it monitors. It runs in its own environment, separate from the sites it tracks, and it only has read access. If something falls over, the monitoring doesn't fall over with it; otherwise you are in the dark at exactly the worst moment.
One verdict a day, no screen to keep an eye on. Every morning at eight, one message came in: what crossed a limit, or confirmation that everything stayed within them. A dashboard you have to open to find out whether you need to open it solves nothing.
The limits live in one place. What counts as ‘too slow’ or ‘too expensive’ is set on the server: one definition that feeds both the morning message and the dashboard. Otherwise you get exactly the problem you set out to solve: two screens saying different things.
What can't be measured reliably, I don't measure. One provider reports compute-time figures that are demonstrably wrong. Those were taken out instead of kept with a caveat; a number you know to be wrong does more harm than no number.
Technical details
Technologies used
- Google Cloud Run
- BigQuery
- Terraform
- Next.js
- TypeScript
- Lighthouse
- Search Console API
- Sentry
What it delivered
The figure that matters most isn't in a table: more than once, the system flagged a small mistake that would have cost money had it stayed, the kind of usage that quietly builds up until it shows on your bill. That is what it was built for: not to warn when something is broken, but when something is slowly heading the wrong way.
The daily overview simply became part of the morning. It arrived in the chat where the rest of the work also came through: no extra screen to open, no habit to learn. And the whole thing was built in about 26 hours over two days: eleven collectors, the complete database set-up, authentication and 83 tests. That pace doesn't come from working hard but from the way of working: built together with AI agents, with me as the one who decides what goes in.
- Places to look
- Nothing left to look up by hand
- Six separate dashboards → One message a day
- Monitored sites and signals
- 11 collectors, each on its own schedule
- Manual, irregular → 4 sites, 9 kinds of signals
- Build time
- Including 83 tests
- — → ~26 hours over two days
Delivered
- 4 sites on 9 kinds of signals
- 11 collectors, daily message at 08:00
- 83 automated tests
- Rising usage caught more than once before it cost money
Outcomes
- Rising usage caught more than once before it showed on the bill
- The daily overview arrived where the work already came through
- Limits live in one place, so message and dashboard don't contradict each other
- The monitoring is separate from what it measures, so it doesn't go down with it
What I take forward
Lessons
- One verdict a day is usable; ten dashboards are not
- Limits belong in one place; two definitions of ‘too slow’ are guaranteed to give two answers
- A monitoring system that depends on what it measures measures nothing at the moment it matters
- Leaving out unreliable figures is better than showing them with a footnote
- Monitoring is most useful for what is slowly heading the wrong way
What was tried out here, I take into client work: one summary message instead of a dashboard, limits in one place, and the rule that a monitoring system must never depend on what it measures.