An Anomaly in the Numbers. Here's the Order to Check Things In.

A metric jumps 15% and the room starts guessing. New campaign. Pricing change. Competitor stumbled. "I think it did this last year around the same time."

Those are business explanations, and people reach for them first because they sound like the interesting answer. They also tend to be the least likely and the most expensive to test. Somebody spends a week building an analysis that proves or disproves a theory a two-minute check would have killed.

There is a method that costs almost nothing and narrows the problem before anyone has to theorize. It starts at the database.

Why the database is the first stop

Every data system has the same basic shape. Upstream, source systems and pipelines collect and load the data. Downstream, dashboards and reports filter and display it. The database sits in the middle.

That position makes it the natural starting point, because one query against the raw table, compared to the number on the report, cuts the problem in half. You will know immediately whether the issue is above you or below you in the stack.

If the database agrees with the report

The report is doing its job. The problem is upstream. Something changed in how the data arrived, and you can find it without leaving the database.

Check the shape of the data first. Run row counts by day against the same period from the prior month. A load that ran twice, or a backfill that someone kicked off without flagging it, shows up here in about ninety seconds. This single check explains more 15% jumps than every other cause on this list combined. It is unglamorous and it is almost always the answer.

Then check the definitions. Pull the distinct values from every categorical field that feeds the metric's filter or grouping. When a source system starts writing "Completed" where it used to write "complete," every downstream filter that matches on the old string silently drops rows. This is rarely your team's doing. It is the sales ops manager renaming a picklist value in the CRM, or IT rolling out a vendor update to the ERP. They changed something in their system. Your pipeline happens to pull from it. They had no reason to tell you because from their side it was a configuration change, not a data change. The fix is straightforward once you find it, but finding it means checking the audit log on the source system, not your own codebase. The total number of rows will look normal. The change hides inside the values, not the volume.

Then check the population. Not the metric, the denominator. A large account onboarding in the middle of a reporting period, a region going live, a test group merged into production. If the denominator shifted, the rate shifted, and the thing that changed is the composition of the group being measured, not anything the group did.

If the database disagrees with the report

The data is fine. The problem is downstream, which means something between the database and the screen changed how the number is being presented.

Check the time window. "This month" means something different on the first of the month than it did yesterday. A dashboard showing a rolling 30 days and a report showing the calendar month will agree for most of the month and then diverge at the boundary. Finance closes the books on the 25th, operations reports through the 1st, and marketing pulls a trailing four weeks. Three departments, three different definitions of "this month," all of them defensible, none of them labeled. When the metric lives in a dashboard that just says "Monthly," nobody knows which definition is in play until the numbers stop matching.

Check the refresh. If the dashboard is showing last Tuesday's numbers because a scheduled refresh failed silently, the metric didn't move. The view froze. This is more common than anyone who hasn't debugged dashboards would expect, because most BI tools fail their refreshes quietly and display stale data without indicating the age. The tell is comparing the dashboard's last-updated timestamp to the current time. If that timestamp is missing or buried in a menu nobody opens, the dashboard has been designed to hide the very information that would make this check instant. That design choice has cost more collective analyst-hours than any single bug I can name.

Where marketing fits

A marketing campaign that moves a number 15% should appear on the marketing calendar before it appears in the data. If nobody on the marketing team expected the jump, it is probably not marketing. That hypothesis gets confirmed or killed with one message to the team, not a week of analysis. Good communication between departments means that campaign launches, pricing changes, and seasonal promotions are known quantities. They are the expected anomalies, and treating them as the default explanation for unexpected anomalies wastes the most expensive resource on the team. An analyst's focused week.

Why teams run it backwards

The boring explanations feel like accusations. Asking whether the pipeline double-loaded implies that somebody's pipeline double-loaded. Checking whether a field definition changed implies that somebody changed it without telling anyone. So the room opens with the flattering hypothesis, the one where the business did something right, and spends a week chasing it.

Making the database check a standing first step, run by default before anyone theorizes, takes the blame out of it. It is not an investigation. It is a two-minute triage that determines whether the rest of the conversation is about plumbing or about the business. Most of the time, it is plumbing, and the meeting ends before it starts.

The order matters because it is cheap at the top and expensive at the bottom. A row-count query costs nothing. An analyst chasing the wrong theory for a week costs the company 2% of that person's annual output. Running them in that order means you never burn that week when a query would have been enough.

The next time a number moves, open a SQL client before you open a meeting invite. Compare the raw table to the report. You will know within two minutes whether the conversation is about data or about the business, and most of the time, the meeting becomes unnecessary.