A number on the dashboard gets questioned in a meeting. Nobody can prove who is right, and within ten minutes a room full of expensive people is arguing about a spreadsheet instead of making a decision. I have sat in that room. So have you. The coffee goes cold, the meeting runs long, and everyone leaves agreeing on exactly one thing: the dashboard is wrong. What nobody says is which problem they are looking at, because most teams never learned the difference between data quality, data reliability, and data observability.
“The dashboard is wrong” is not a diagnosis. It is a feeling. And you cannot assign a feeling to an engineer and expect a fix by Friday.
Almost every “the number looks off” complaint is one of three very different problems wearing the same coat. Tell them apart and the panic drops, because the work becomes obvious.
One complaint, three different problems
From the outside all three look identical: a number nobody trusts. What separates them is what broke underneath, and that decides who fixes it.
Problem one: data quality
Data quality is about the values themselves. Are they fit for use?
A duplicate order slips into the table and revenue jumps. A region code is blank, so a real sale belongs to no territory and vanishes from the regional report. A date sits in the future because someone typed 2027.
The tell is that you can point at one row and one field and say: this value is wrong.
-- The duplicate that made finance briefly very happy
SELECT order_id, COUNT(*)
FROM sales_orders
GROUP BY order_id
HAVING COUNT(*) > 1;If that query returns rows, the fix lives close to the data. Reject it, flag it, or backfill it. Straightforward, as these things go.
Problem two: data reliability
Reliability is the sneaky one. It has nothing to do with whether the values are correct. It is about whether the data showed up.
A daily feed loads at 6 am so the numbers are ready for the 9 am review. One morning the load fails. Nobody notices, because yesterday’s data is still sitting there, calm and complete. Every value is correct. Every value is also a day old.
The dashboard is telling a story from yesterday while the room treats it as today. Nothing looks broken. The rows are valid, the totals add up, and the only thing wrong is the clock. Reliability points you at the pipeline and the schedule, never at the value.
Problem three: data observability
Observability is the one that produces the sentence “I have no idea why this happened.”
Something shifts upstream. A column that held five product categories now holds eight. A source system starts sending amounts in cents instead of dollars. No rule caught it, because nobody writes a rule for a change they did not see coming.
Observability is the difference between “revenue doubled overnight and we lost two days working out why” and “revenue doubled overnight and lineage pointed at the currency change in ten minutes.”
The three questions that keep them straight
When someone brings you a wrong number, ask these in order.
| Ask this | If yes, it is a | And you fix it by |
|---|---|---|
| Is a value wrong or missing? | Quality problem | Fixing, flagging, or backfilling the row |
| Are the values fine but late? | Reliability problem | Checking the pipeline and schedule |
| Did something change and no rule saw it? | Observability problem | Tracing lineage back to the source |
The same complaint sends you to three different places. Fix the row, check the pipeline, or trace the lineage. Hand a reliability problem to the person who owns data cleaning and they will stare at perfectly valid rows for an hour and find nothing, because the rows were never the problem.
Why the label is the whole game
Naming the problem is not tidiness. The name decides who owns the work and what happens next.
“The dashboard is wrong” bounces from inbox to inbox because nobody can tell whose it is. Rewrite it as “revenue is overstated because duplicate order ids are in the sales extract” and suddenly there is a field, a cause, and an owner. Same problem. Completely different Tuesday.
You did not need a new tool for that. You needed a clearer sentence.
Try this on Monday
Next time someone says the numbers look off, do not open the query editor. Ask the three questions first. Within a minute you will know whether you are chasing a value, a schedule, or a change, and that minute saves the afternoon.
Get the name right and the fix is already half done. The other half is typing.
If you want to go deeper, I walk through data quality, reliability, and observability with worked examples in my Pluralsight course, Introduction to Data Quality and Observability.
Reference: Pinal Dave (https://blog.sqlauthority.com/), X
