Why Your Dashboard Shows Wrong Numbers (And How to Fix It)

It's the nightmare scenario for any data team: a stakeholder finds wrong numbers in a critical dashboard. Maybe revenue is showing $0. Maybe customer counts dropped by half. Maybe yesterday's data is just... missing.

The pressure is immediate. Leadership wants answers. You're scrambling through logs, checking pipelines, and trying to explain something you don't yet understand.

This guide will help you systematically debug data discrepancies—and more importantly, prevent them from happening in the first place.

The Most Common Causes of Wrong Dashboard Data

1. Stale Data (Data Freshness Issues)

Symptom: Numbers look "frozen" from a previous day, or there's a sudden drop in recent metrics.

What happened: Your ETL job failed, was delayed, or is still running. The dashboard is showing old data as if it were current.

How to verify:

-- Check when data was last updated
SELECT
  MAX(updated_at) as last_update,
  DATEDIFF(hour, MAX(updated_at), CURRENT_TIMESTAMP) as hours_stale
FROM your_table;

-- Compare today's row count to previous days
SELECT
  DATE(created_at) as date,
  COUNT(*) as row_count
FROM orders
WHERE created_at > CURRENT_DATE - 7
GROUP BY DATE(created_at)
ORDER BY date DESC;

Fix: Check your orchestration tool (Airflow, dbt Cloud, Dagster) for failed or delayed jobs. If the job failed, identify why and rerun it. Set up freshness monitoring to catch these issues automatically.

2. Partial Data Loads

Symptom: Numbers are lower than expected, but not zero. Trends look correct but magnitudes are off.

What happened: Your pipeline loaded some data but not all of it. This often happens with API pagination issues, timeout errors that didn't surface, or filters that accidentally excluded records.

How to verify:

-- Compare counts against source (if accessible)
-- In your source system:
SELECT COUNT(*) FROM source_orders WHERE date = '2025-12-21';

-- In your warehouse:
SELECT COUNT(*) FROM warehouse.orders WHERE date = '2025-12-21';

-- Check for gaps in IDs (if sequential)
SELECT
  MAX(order_id) - MIN(order_id) + 1 as expected_count,
  COUNT(*) as actual_count,
  MAX(order_id) - MIN(order_id) + 1 - COUNT(*) as missing_records
FROM orders
WHERE date = '2025-12-21';

Fix: Implement row count validation as part of your pipeline. Compare loaded counts against source counts or historical averages. Add anomaly detection on volume metrics.

3. Schema Changes Upstream

Symptom: Specific columns are NULL, wrong, or calculations produce unexpected results.

What happened: Someone in an upstream system renamed a column, changed a data type, or modified a table structure. Your pipeline didn't error—it just started producing wrong data.

How to verify:

-- Check for NULL values that shouldn't exist
SELECT
  COUNT(*) as total_rows,
  COUNT(revenue) as rows_with_revenue,
  SUM(CASE WHEN revenue IS NULL THEN 1 ELSE 0 END) as null_revenue
FROM orders
WHERE date = CURRENT_DATE - 1;

-- Check data types
SELECT
  column_name,
  data_type
FROM information_schema.columns
WHERE table_name = 'orders';

Fix: Implement schema monitoring to detect changes immediately. Establish data contracts with upstream teams. Use schema validation in your ingestion layer.

4. Broken Joins

Symptom: Aggregated numbers (especially sums) are way off—either too high (duplicates) or too low (missing matches).

What happened: A join key changed, creating either a many-to-many explosion (duplicates) or a failed match (lost records). This is especially common when joining fact tables to dimension tables.

How to verify:

-- Check for join explosion (duplicates)
SELECT
  order_id,
  COUNT(*) as times_appearing
FROM revenue_report
GROUP BY order_id
HAVING COUNT(*) > 1
LIMIT 10;

-- Check for orphaned records (missing dimension)
SELECT COUNT(*) as orphaned_orders
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
WHERE c.customer_id IS NULL;

-- Compare granularity
SELECT
  COUNT(*) as fact_count,
  COUNT(DISTINCT order_id) as unique_orders
FROM revenue_report;

Fix: Add referential integrity tests to your pipeline. Test that join keys are unique where expected. Monitor for orphaned records. Use data lineage to understand relationships.

5. Business Logic Changes

Symptom: Numbers are different, but you can't find anything wrong with the data itself.

What happened: Someone changed a calculation, filter, or aggregation logic. Maybe "active customers" now excludes trial users. Maybe revenue now includes refunds. The data is "correct"—the definition changed.

How to verify:

• Check git history for recent changes to transformation models
• Review dbt model changes in the last 24-48 hours
• Ask stakeholders if any metric definitions changed
• Compare your transformation logic against documentation

Fix: Version your metric definitions. Require code review for transformation changes. Add semantic layer documentation. When definitions change, communicate proactively.

6. Timezone and Date Boundary Issues

Symptom: Numbers are wrong at day/week/month boundaries. "Yesterday's" data includes some of today's, or vice versa.

What happened: Inconsistent timezone handling between source systems, transformations, and the dashboard. Data recorded in UTC is displayed as if it were local time (or vice versa).

How to verify:

-- Check timestamp distribution around midnight
SELECT
  DATE(created_at) as date,
  EXTRACT(hour FROM created_at) as hour,
  COUNT(*) as count
FROM orders
WHERE created_at BETWEEN '2025-12-21' AND '2025-12-22 02:00:00'
GROUP BY DATE(created_at), EXTRACT(hour FROM created_at)
ORDER BY date, hour;

-- Compare different timezone interpretations
SELECT
  DATE(created_at AT TIME ZONE 'UTC') as utc_date,
  DATE(created_at AT TIME ZONE 'America/New_York') as et_date,
  COUNT(*)
FROM orders
WHERE created_at > '2025-12-21'
GROUP BY 1, 2;

Fix: Standardize on UTC for all storage. Convert to local time only at the presentation layer. Document timezone assumptions in your data dictionary.

A Systematic Debugging Process

Step 1: Define the Problem Precisely

Before diving into queries, answer these questions:

• Which specific metric is wrong? "Revenue is off" vs "Q4 revenue in the US region for enterprise customers is off"
• When did it start? Find the first date where data diverges from expected
• What's the expected value? Get a benchmark from another source if possible
• Who reported it? They may have additional context

Step 2: Check the Obvious First

80% of data issues come from a few common causes. Check these first:

1. Data freshness: When was the table last updated?
2. Job status: Did all ETL jobs complete successfully?
3. Row counts: Is the expected volume there?
4. Recent deployments: Did any code change in the last 24-48 hours?

Step 3: Trace the Lineage

Work backwards from the dashboard:

1. Dashboard level: What tables/queries power this visualization?
2. Presentation layer: Are there calculations in the BI tool?
3. Mart/report tables: Is the aggregated data correct?
4. Transformation layer: Are intermediate models correct?
5. Staging layer: Is raw data making it in correctly?
6. Source systems: Is the source data correct?

At each level, compare expected vs actual. The point where they diverge is where your bug lives.

Step 4: Isolate the Variable

Once you've narrowed down the layer, isolate what changed:

• Compare today's data to yesterday's at the same layer
• Check git history for recent changes
• Look for schema changes in affected tables
• Check for NULL or unexpected values in key columns

Step 5: Fix and Verify

Once you find the root cause:

1. Fix the immediate issue
2. Backfill affected data if needed
3. Verify the dashboard shows correct numbers
4. Add monitoring to prevent recurrence
5. Document the incident for future reference

Preventing Wrong Dashboard Data

Implement Data Observability

The best way to handle wrong data is to catch it before stakeholders do. Data observability provides automated monitoring for:

• Freshness: Alert when data goes stale
• Volume: Alert when row counts are abnormal
• Schema: Alert when columns change
• Distribution: Alert when values fall outside expected ranges

Add Data Tests to Your Pipeline

Use tools like dbt tests or Great Expectations to validate data at every transformation step:

# Example dbt schema tests
models:
  - name: orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: revenue
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0
              max_value: 1000000
      - name: customer_id
        tests:
          - relationships:
              to: ref('customers')
              field: customer_id

Establish Data Contracts

Work with upstream teams to define expectations:

• Document expected schemas
• Define SLAs for data delivery
• Establish communication channels for breaking changes
• Version your data interfaces

Create Runbooks

When an issue happens at 3am, you'll be glad you documented:

• Common failure modes and their fixes
• Key queries for diagnosis
• Escalation paths and contacts
• Data lineage for critical tables

Frequently Asked Questions

Why does my dashboard show different numbers than yesterday?

Dashboard numbers can change due to late-arriving data (common with event data), ETL reprocessing (backfills), schema changes upstream, or business logic updates. Check your data freshness timestamps and compare row counts with previous days to identify when the discrepancy was introduced.

How do I debug wrong numbers in my data dashboard?

Start by identifying when the issue began and which specific metrics are affected. Then trace the data lineage backwards from the dashboard through transformations to source systems. Check for schema changes, failed ETL jobs, and data quality issues at each stage. Most issues are found in freshness, volume, or join problems.

Why is my revenue showing $0 or NULL?

Zero or NULL revenue typically indicates a broken join (missing dimension keys), a failed data load, or a schema change in source tables. Check if your fact table has the expected row count and if join keys match between tables. Also verify that the revenue column itself hasn't been renamed or moved.

Conclusion

Wrong dashboard data is inevitable—but data incidents don't have to be. With systematic debugging processes and proactive monitoring, you can catch issues before stakeholders do and resolve them quickly when they happen.

The key is shifting from reactive firefighting to proactive observability. Monitor your data's freshness, volume, schema, and distribution continuously. When something goes wrong, you'll know immediately—and you'll have the context to fix it fast.