Building OCI Dashboards

There is a particular kind of dashboard that gets built in a hurry, usually the week before a launch, and then quietly stops being looked at. It has every metric anyone could think of, arranged in whatever order they were added, with no clear sense of what the viewer is supposed to take away. When something goes wrong, nobody opens it, because it has never once told them anything useful. The problem is not the tooling. The OCI Monitoring service can chart almost anything. The problem is that the dashboard was built around what was available to plot rather than around the question a person needs answered when they glance at the screen. A dashboard that does not answer a question is decoration.

This article is about building dashboards that earn their place on a wall or a browser tab. The principles are not specific to OCI, but the examples are, and the goal throughout is the same: a person should be able to look at the dashboard for three seconds and know whether to relax or to act.

Start with the audience and the question

Before choosing a single metric, decide who the dashboard is for and what decision they make with it. An on call engineer at three in the morning wants to know one thing: is the service healthy, and if not, where is the problem. An executive wants a different thing entirely, a sense of whether the platform is meeting its commitments over the month. A capacity planner wants trends stretching back weeks. These are three different dashboards, and trying to serve all of them from one screen produces something that serves none of them. Name the audience, write down the question in a sentence, and let that sentence govern every choice that follows.

The four kinds of dashboard

Most dashboards fall into one of a few types, and knowing which type you are building keeps the layout honest. The table below lays out the common ones, who reads them, and what they should show.

The service health dashboard is the one that matters most in a crisis, so it deserves the most care. It should show the few signals that tell you the service is working, the rate of requests, the rate of errors, the latency, and the saturation of the resources behind it. These four together, often called the golden signals, are enough to tell whether a service is healthy and to point at the layer where a problem lives. Everything else is detail to add once those four are in place.

Choosing metrics that mean something

The temptation is to plot every metric OCI emits. Resist it. A metric belongs on a dashboard only if a change in it would cause someone to act. CPU utilisation on a database is worth showing because sustained high utilisation means trouble is coming. The count of API calls to the monitoring service itself is not, because nobody changes their behaviour based on it. For each candidate metric, ask what action a viewer would take if the line moved, and if the honest answer is none, leave it off. This single discipline removes most of the clutter that makes dashboards unreadable.

Tie the metrics you keep to the targets you care about. If your service has a latency objective, the latency chart should show the target as a line, so the viewer sees not just the current value but whether it is inside the promise. This connects the dashboard to your service level objectives and turns a raw number into a judgement. A chart with a threshold drawn on it is worth several charts without one.

Layout that respects the eye

People read a screen top left to bottom right, and they trust the top of the screen more than the bottom. Put the most important signal, the one that answers the headline question, at the top left where the eye lands first. Group related charts together so the viewer can scan a region rather than hunt across the whole screen. Keep the number of charts small, because a dashboard with eight focused panels is read and a dashboard with thirty is ignored. Use consistent colour, where the same colour always means the same thing, so green is always healthy and red is always trouble, and never use colour decoratively in a way that competes with that meaning.

Avoiding the wall of green

A common failure is the dashboard that is always green. It feels reassuring, but a dashboard that is never anything but green has stopped carrying information, because the viewer learns that the colour means nothing. The cause is usually thresholds set so loosely that they never trip, or aggregations so coarse that real problems average away. The fix is to set thresholds at levels that actually distinguish healthy from unhealthy, the same levels that drive your alarms and alerts, so that the colour on the dashboard agrees with the alerting. When the dashboard and the alarms tell the same story, both become trustworthy. When they disagree, people stop believing either.

A framework for building a useful dashboard

The order below produces a dashboard people return to rather than one that gathers dust.

Building dashboards in OCI

The OCI console provides dashboards that pull from the metrics gathered by the platform, described in detail in the monitoring service explainer. You can build service dashboards directly there, combining the metrics OCI emits for compute, databases, networking, and load balancers into a single view. For teams that already run a visualisation tool, the same metrics can flow outward, and integrating OCI with Grafana lets you build these dashboards in a familiar place alongside data from elsewhere. Either way, the principles hold. The tool charts what you ask it to. Your job is to ask for the few things that answer the question.

Good dashboards are a small discipline with a large payoff. They are the face your team sees every day and the first place anyone looks in an incident. Built around a question, kept small, and reconciled with the alarms, they become trusted. Built as a dumping ground for every available metric, they become wallpaper. This work sits within the wider practice covered in the complete monitoring and observability guide, and when you want dashboards designed around the decisions your team actually makes, our OCI monitoring and observability practice builds them this way.