Dashboard Averages: Is Every Job Counted Equally, or Every Team?

Before commissioning a dashboard that shows an average, ask what receives equal weight: each job, each day or each team. These are different questions. A neat overall figure can answer the wrong one even when every displayed team average is correct.

This guide concerns arithmetic averages in an internal business app. It is not a method for calculating statutory financial results or a recommendation to rank employees by a single number. Start with the operational decision the report must support.

Name one observation

A fictional repair business wants to understand the recorded duration of completed jobs. Write down what a job means, which completion event qualifies it and whether duration means hands-on work or elapsed time. Do not combine those two measurements under one heading.

Agree how reopened jobs, cancelled work and records spanning the reporting boundary are treated. For a report of jobs completed this month, the inclusion rule differs from a report of work performed this month. Put that definition near the report or in an accessible explanation.

Then name the weighting unit. “Average recorded minutes per completed job” says more than “average performance.” If the intended question is about a typical team's workload, an equally weighted team measure may be appropriate, but it must not be labelled as the average job.

Do not average group averages without choosing that meaning

Consider a deliberately simplified test. One team completes two jobs, each taking ten minutes. Another completes eight jobs, each taking thirty minutes. The simple average of the two team averages is twenty minutes. The average across all ten jobs is twenty-six minutes.

Neither result is a mysterious software error. The first gives the small and large team equal weight; the second gives each job equal weight. Choose the question before approving the headline figure.

Ask the developer to retain the underlying total and eligible observation count for each group, or calculate from the eligible individual records. Do not use already rounded display averages as the only input to the combined report. Grouping by team and then by day should not accidentally change a metric defined per job.

A missing duration is not a zero-minute job

PostgreSQL 18's aggregate reference says that its average function uses non-null input values. It separately distinguishes counting all input rows from counting rows with a non-null value. These are documented database behaviours, not proof of how your application currently stores incomplete records.

For the proposed report, show both the eligible job count and the count with usable duration data. If a duration is absent, decide whether the report excludes it with a visible coverage warning or refuses to show a supposedly complete result. Do not insert zero simply to make a chart render.

A genuinely measured zero, an absent measurement and an invalid negative duration need separately agreed treatment. Explain any exclusion, assign responsibility for correcting the source data and avoid inventing a plausible replacement.

Keep an empty report honest

The same PostgreSQL reference notes that a sum over no rows returns null rather than zero. A developer can substitute a display value, but that technical choice should follow the business meaning.

Specify different messages for no eligible jobs, eligible jobs with no usable measurements and a failed data load. None should appear as a successfully measured average of zero. A stale cached result should retain its relevant period and freshness indication rather than borrowing the current page-load time.

Accept the roll-up, not just the chart

Use the unequal-team example in your acceptance criteria. Confirm the expected result when viewing all jobs and when grouping them by team. Add a missing duration, a genuine zero, an excluded cancelled job and an empty period. Compare the screen and export under the same filters.

Ask whether a user who can see only part of the data receives a personal-scope metric or an explicitly authorised wider aggregate. Do not expose restricted underlying records just to explain a total.

Bring the chosen observation, weighting rule and missing-data policy to a reporting-app discussion. A useful average has a named denominator and an explainable route back to its inputs, not merely a convincing chart.

Source and limits

PostgreSQL 18 aggregate documentation, read 26 October 2026, supports the descriptions of non-null averaging, counting and empty aggregates. The fictional arithmetic example was calculated separately. Report definitions, visibility rules and tests are commissioning guidance, not features verified in a deployed app.