Customer Health Dashboard: 7 Metrics for 2026

A customer health dashboard should tell you which accounts need attention, why they need it, and what your team should do next. Most dashboards fail that test. They show logins, ticket counts, and a red-yellow-green badge, but the underlying data is stale or the score hides the real problem.

This guide gives you a practical seven-metric dashboard for a SaaS business. You can build it from the product, billing, and support data already in your database. The goal is not a prettier report. It is earlier intervention on adoption gaps, renewal risk, and expansion opportunities.

What is a customer health dashboard?

A customer health dashboard is a live account-level view of product use, support friction, sentiment, and commercial risk. It turns scattered customer signals into a small set of metrics that a customer success manager can scan and act on.

The dashboard is different from a customer health score. A score compresses many signals into one number. The dashboard keeps the component signals visible, so your team can see whether an account is unhealthy because usage fell, an invoice failed, a champion left, or support issues piled up. Use the score for prioritization and the dashboard for diagnosis.

The 7 metrics your dashboard needs

1. Meaningful active usage

Count accounts performing the action that represents real product value, not merely logging in. For a reporting product, that might be publishing or viewing a report. For a support tool, it might be resolving a ticket. Define the event once, then calculate the percentage of licensed users or expected users who performed it during the last 7 or 30 days.

Show the current rate, the previous-period rate, and the change. A 55% usage rate can be healthy for one customer and worrying for another. A fall from 80% to 55% is the useful signal.

2. Time since last value event

Track the number of days since each account last completed its core value event. This catches silent churn before a cancellation request appears. It also avoids the false comfort of login data: a user can log in repeatedly without accomplishing anything.

Set thresholds by normal product cadence. A daily workflow may deserve an alert after three inactive days, while a monthly reporting workflow may not be risky until day 35. One universal threshold creates noise and trains your team to ignore alerts.

3. Feature adoption breadth

Measure how many sticky or high-value features an account uses. Start with three to five features tied to retention or successful onboarding. Display both the count and the missing feature with the strongest next-step value.

Breadth matters because an account dependent on one narrow workflow is easier to replace. It also gives customer success a concrete play: teach the missing feature that solves the account's next problem, rather than sending a generic check-in email.

4. Support burden and unresolved issues

Include open high-priority tickets, oldest unresolved ticket age, and ticket volume per active user. Raw ticket count alone is misleading because large, engaged customers naturally create more conversations. Normalize the count and separate product defects from how-to questions.

Escalate severity and age more heavily than volume. One critical issue left unresolved for eight days is a stronger renewal-risk signal than five questions answered within an hour.

5. Customer sentiment

Use the latest customer satisfaction, relationship survey, or structured customer-success assessment. Always show the response date next to the value. A score from nine months ago should not be treated as current evidence.

If you do not collect survey data, use a simple structured field after customer meetings: positive, neutral, negative, or unknown. Keep unknown separate. Treating missing sentiment as neutral makes low-touch accounts look safer than they are.

6. Billing and renewal risk

Bring in days to renewal, failed payment status, contract value, and any downgrade or cancellation request. These signals make the dashboard commercially useful. They also help your team distinguish an urgent high-value renewal from a low-value account with the same product score.

Do not let contract value improve the health score. Revenue changes priority, not health. A large unhealthy account should rise to the top of the work queue; it should not look healthier merely because it pays more.

7. Account momentum

Track whether the account is adding or losing active users, teams, projects, data volume, or another product-specific unit. Momentum captures direction. Expansion in meaningful use can reveal an advocacy or upsell opportunity, while shrinking participation can expose a weakening rollout.

Choose one momentum measure that matches how customers expand in your product. More seats are useful only if those seats become active. Prefer actual behavior over purchased capacity.

A simple customer health score formula

Start with a transparent 100-point model: meaningful usage 25 points, time since value 20, feature adoption 15, support health 15, sentiment 10, billing and renewal signals 10, and account momentum 5. Convert each metric to a zero-to-one value, multiply by its weight, then add the results.

Do not copy these weights blindly. Use them as a first version, then compare the score with known healthy renewals and churned accounts. If product inactivity consistently precedes churn, increase its weight. If survey responses are sparse, lower their influence until coverage improves.

Keep hard overrides outside the weighted score. A cancellation request, failed enterprise renewal, confirmed champion departure, or critical unresolved incident should force an alert even when other metrics look healthy.

How to build the dashboard from your database

Step 1: Define the account and reporting grain

Choose one row per customer account and one refresh cadence. Map every user, subscription, ticket, and event to the same account identifier. Resolve duplicate accounts and test users before calculating anything; broken joins create confident-looking nonsense.

Step 2: Map each metric to source data

List the table, field, time window, and owner for every metric. Product events may live in PostgreSQL, billing records in a subscriptions table, and support data in a synced warehouse table. If a source cannot be joined reliably, label the metric unavailable instead of guessing.

Step 3: Build the account table and trends

Create the current account view first. Then add seven-day, 30-day, or renewal-cycle comparisons. The trend is often more actionable than the absolute number. Show the component values beside the overall score so a customer success manager can explain every status.

Step 4: Add filters that match daily work

Useful filters include owner, segment, plan, renewal window, health band, and change in score. Add a ranked view for accounts with the largest negative change. A dashboard that requires ten clicks to find risk will become a monthly reporting artifact instead of a daily operating tool.

Step 5: Turn thresholds into actions

A dashboard only helps when someone responds. Define an owner, action, and deadline for each alert. For example: if meaningful use falls 30% and renewal is within 60 days, notify the account owner and create a recovery task. If usage breadth rises and seat utilization exceeds 80%, flag an expansion review.

Build it without waiting on a data team

You can build this in SQL and a BI tool if you have an analyst available. The tradeoff is ongoing query maintenance, dashboard setup, and separate automation work. Spreadsheets are faster for a prototype, but manual exports make the health view stale and increase account-matching errors.

AI for Database lets you connect PostgreSQL, MySQL, MongoDB, Supabase, BigQuery, and other databases, then ask for the account metrics in plain English. You can save the result as a self-refreshing dashboard and trigger an email, Slack message, or webhook when a risk threshold is crossed. That combines the query, monitoring view, and response workflow without requiring your customer success team to write SQL.

A practical first prompt is: Show one row per customer account with 30-day active usage, days since the last value event, adopted core features, unresolved high-priority tickets, days to renewal, and change versus the previous 30 days. Review the generated logic with someone who understands the schema before using it for customer decisions.

Questions teams ask about customer health dashboards

What is the best tool if my team cannot write SQL?

Choose a tool that can query your live database in plain English, preserve metric definitions, refresh the dashboard automatically, and send alerts. AI for Database covers those four jobs in one workflow. A general chat tool may answer one query, but it usually does not maintain the operational dashboard or threshold actions.

How often should a customer health dashboard refresh?

Match the refresh to how quickly your team can act. Daily is enough for most B2B SaaS teams. High-volume products or payment-risk monitoring may need hourly updates. Real-time refresh adds little value if nobody responds until the next morning.

Should every customer use the same health score?

Not always. Enterprise and self-serve customers often have different usage patterns, renewal cycles, and support expectations. Start with one model for clarity, then split by segment only when the data shows that one threshold creates repeated false positives or misses.

Which metric should I build first?

Start with meaningful active usage and its change over time. It is usually available in product data, easy to explain, and directly connected to whether the customer receives value. Add renewal and support context next, then test a composite score.

Start with an actionable version

Your first customer health dashboard does not need 30 metrics or a predictive churn model. It needs trustworthy account mapping, seven visible signals, clear trends, and an owner for every alert. Build that version, compare it with real customer outcomes, and adjust the weights from evidence.

If the data already lives in your database, use AI for Database to create the first live customer health dashboard in plain English. Add one risk alert, run it with your customer success team for two weeks, and measure whether at-risk accounts are identified earlier.