ServiceNow Performance Analytics Health Check

A Performance Analytics health check decides what to do with each dashboard it finds, and repairs the calculations that disagree with each other. This page covers dashboard inventory and usage, metric accuracy and data validation, KPI alignment with business objectives, target setting, drill-down capability, stakeholder trust, governance and metric maintenance, integration with incident and change data, where health checks go wrong, and when one should not go ahead.

Dashboard Inventory and Usage Analysis

We audit Performance Analytics dashboards: what dashboards exist, who is supposed to use each, how frequently are dashboards accessed. We measure dashboard usage: do dashboards show meaningful usage or are they rarely viewed. Common findings: dashboards were built during project implementation but aren’t regularly viewed, dashboard creation has no governance so dozens of dashboards exist, most dashboards aren’t useful to anyone. We also measure: dashboard load performance (do dashboards respond quickly or frustrate users), dashboard data freshness (are dashboards showing current data or outdated). We assess: are dashboards solving real business problems or just creating reports.

Metric Accuracy and Data Validation

Dashboards are only as good as underlying data. We assess: how are metrics calculated, are calculation methods documented, are calculations correct. We sample verify: pull underlying data, validate metric calculations, confirm numbers make sense. Common findings: metric calculations have errors (divide by zero bugs, incorrect grouping), metrics are calculated inconsistently across dashboards (same metric shows different numbers in different dashboards), data is stale or incomplete. We also assess: how much data goes into each dashboard, is data volume causing performance issues, are aggregations correct. We measure: data quality (are underlying tables accurate and complete), calculation correctness (do indicator results match manual validation). We assess: can stakeholders trust dashboard numbers, or should they verify data independently.

KPI Alignment with Business Objectives

KPIs should align with what business cares about. We assess: do KPIs reflect business priorities, are KPIs balanced (financial, operational, customer satisfaction), do KPIs create alignment across teams. Common findings: KPIs are IT-centric (incident counts, change volume) rather than business-aligned, KPIs don’t reflect what leadership cares about, too many KPIs creating confusion about priorities. We interview stakeholders: what metrics do you check, what decisions do you make from these metrics, what information are you missing. We assess: are dashboards showing what stakeholders actually need to manage business.

Target Setting and Performance Achievement

Metrics without targets are just numbers. We assess: are targets defined for KPIs, are targets realistic and achievable, are teams actually trying to meet targets. We measure: performance versus target, trends (improving or declining), consistency (some teams meet targets while others consistently miss). Common findings: targets aren’t communicated clearly, targets are aspirational but no resources are allocated to achieve them, targets haven’t changed in years despite organizational changes. We assess: do targets motivate and align behavior, or create frustration with unrealistic expectations.

Drill-Down Capability and Root Cause Analysis

Dashboards identify problems (metric is off-target). Drill-down capability helps diagnose causes. We assess: can stakeholders drill down to details, is drill-down path logical and easy to navigate, do drill-down reports answer questions that drill-down raised. Common findings: dashboards identify problems but drill-down doesn’t exist, drill-down reporting is hard to navigate, underlying data lacks dimensions needed to diagnose. We assess: are stakeholders able to investigate problems independently, or do they need analyst help for every question.

Stakeholder Adoption and Trust in Metrics

Dashboards fail if stakeholders don’t trust them. We assess: what percentage of target stakeholders actually view dashboards, do they trust the data, do they use dashboards to make decisions. Common findings: some stakeholders prefer their own spreadsheets (because they don’t trust centralized dashboards), stakeholders don’t understand metric calculations and are skeptical, dashboards are shared but decision-making still happens in isolation. We interview stakeholders: what would make dashboards more useful, what prevents you from trusting these metrics, what information do you need that isn’t available. We assess: are dashboards creating shared understanding or creating conflict (different stakeholders seeing different numbers).

Governance and Metric Maintenance

Dashboards and metrics require maintenance: calculations need verification, indicators need to be reconfigured as business changes, new metrics emerge. We assess: is there governance over dashboard creation (is anyone preventing dashboard sprawl), are metrics reviewed and updated, is there ownership for each dashboard. Common findings: anyone can create dashboards (no governance), dashboards are created for one-time use and never deleted, indicators are calculated wrong but no one maintains them. We assess: is Performance Analytics being actively managed or passively left alone.

Integration with Incident and Change Management Data

Performance Analytics should pull data from ITSM modules. We assess: does Performance Analytics have current connection to incident, change, problem data, are metric calculations accurate based on source data, is data freshness adequate for decision-making. Common findings: connections are configured but broken (data isn’t fresh), metric calculations don’t match how source data is structured, integration requires manual updates. We assess: are Performance Analytics metrics integrated with ITSM or disconnected.

Deciding what to do with each dashboard the review finds

A Performance Analytics review produces a list of dashboards with notes beside them: rarely viewed, numbers that do not reconcile, owner unknown. The temptation is to fix everything, which in practice means rebuilding the most visible dashboards and leaving the rest to decay. A better approach is to make a three-way decision for every dashboard before any build work starts: keep it as it is, repair it, or retire it. Each choice has a different cost and a different owner, and a decision is easier to defend when the evidence sits beside it.

Retirement is the decision most teams resist, because removing a view feels like losing information. In practice, a dashboard that nobody opens and that disagrees with another dashboard is a liability. It consumes build time, it confuses newcomers and it gives a reason to distrust the whole set. Removing it is a governance act, and it should be treated as one.

A repair routine for calculations that disagree

When two views disagree about what should be one measure, the routine below narrows the cause before anyone edits a calculation. It is slower than a quick fix and far less likely to break a second dashboard along the way.

1. Pick one record that appears in both calculations and trace it through each indicator by hand.
2. Note the first point where the two results diverge, which is usually a filter, a group or a time window.
3. Decide which of the two rules matches the written definition, or whether the definition itself needs to change.
4. Change only the calculation that departs from the definition, then recheck both dashboards against the same record.

Where health checks go wrong

A common mistake is to measure viewing counts over a short window that happens to miss a monthly review cycle. A dashboard used only at month end will look dead in a two-week sample. Use a window that covers at least one full governance cycle. A second mistake is asking stakeholders whether they like a dashboard. Ask instead what decision they made from it last time, and what they would have needed to make it faster.

When a health check should not go ahead

If the governance forum that would act on the findings has not met for a long time, the review will produce a report that sits unread. Re-establish the forum first, then review. The same applies if the data feeding the dashboards is being migrated, because the findings would describe a state that is about to change. If the review finds that the gap is really in reporting capacity, ongoing support is the next question. For running that work on an ongoing basis, see the performance analytics managed support service.

Is viewing data enough to judge a dashboard

No. Viewing data shows attention, not usefulness. Pair it with the decisions recorded in governance notes and with a short check of whether anyone changed an action because of what the dashboard showed.

Who should be allowed to create new dashboards after the review

A short list of named creators, with a request route for anyone else who needs a view. Open creation is a common cause of sprawl, and sprawl is a common reason a review finds many near-identical views.

How should retired dashboards be handled

Export the definition, the owner, the last viewing history and the reason for retirement, then remove the view from navigation. Keep the record so that a question about a missing number can be answered later. The explanation of report sources helps identify which views depend on the same underlying data before anything is removed.

Next step

The monitoring dashboard decision guide covers designing dashboards around decisions, which informs the keep-or-retire call.