> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/guides/quality-improvement/coverage-analysis-playbooks/monitoring-ongoing-quality-as-a-team-dashboard.md).
# Monitoring Ongoing Quality as a Team Dashboard
{% hint style="success" %}
**Best for:** QA Managers, Engineering Leads
{% endhint %}
### The Situation
You want a persistent, shared view of quality across a product area, a set of services, or an entire product, something your team and stakeholders can check at any time without anyone having to pull a report. Right now, quality visibility tends to happen in bursts: at the end of a sprint, before a release, or when something breaks. In between those moments, coverage drift can happen silently and accumulate into a problem that's only discovered at the worst time.
This playbook is about establishing an always-on quality baseline for a defined scope; not tracking individual changes or validating a specific release, but maintaining a clear, continuous picture of how well your product is covered overall.
***
### How Coverage Analysis Helps
Coverage Analysis views are saved and automatically refreshed every 15 minutes. Once a view is created for a team or product area, it's accessible to everyone from the view selector, always up to date, no manual intervention needed.
The key metric here is **Overall Coverage** across your full service scope. This tells you, at any point in time, what percentage of your product's code is being exercised by tests, across all services and all test stages together. It's the broadest quality signal available, and the right one for ongoing monitoring where the goal is sustained health, not sprint-level detail.
A rolling date range keeps the view continuously relevant without requiring any reconfiguration. Over time, this view becomes your team's ambient quality signal, a shared reference that makes coverage visible as a routine part of the workflow, not just a pre-release concern.
Views can be exported as PDF for stakeholder updates and as CSV for teams that want to feed coverage data into external reporting or tooling.
***
### Recommended View Configuration
Setting
Value
Date Range
Rolling – Last 7 days (weekly monitoring) or Last 30 days (broader trend)
Code Scope
Full product, application, or team service scope (Saved Scope recommended)
Test Stages
All
Metrics
Overall Coverage
Share the view with your team and stakeholders. Encourage checking it regularly, not just before releases. Use the App tab to spot which services are pulling the overall number down, and use the PDF export for recurring status updates.
***
**Recovery Time After Coverage Drops** When coverage drops — due to a feature push or a period of rapid development — how quickly does it recover? Teams with strong test cultures typically see coverage bounce back within one sprint. A drop that persists for two or more sprints is a sign that test debt is accumulating.
**Quarterly Coverage Trend** Zoom out beyond the weekly view and compare the same rolling window across quarters. A year-over-year improvement of 5–10% in overall coverage, sustained across services, is a strong indicator that quality engineering is becoming embedded in the team's culture.
* **Industry context:** Organizations that treat coverage as an ongoing operational metric — rather than a pre-release checklist item — consistently outperform those that don't on post-release defect rates and mean time to recovery. The key shift is from "are we covered enough to ship?" to "how is our coverage trending over time?"
**Stakeholder Visibility** An indirect but important metric: how often do stakeholders ask for coverage status, and how quickly can you answer? Teams using Coverage Analysis as a persistent dashboard report a significant reduction in the time spent preparing quality updates — the answer is always already available.
### Success Metrics to Watch
#### **Overall Coverage % Across the Full Scope**
This is your headline metric. It represents the health of your entire product area at a glance, the percentage of all methods across all services in scope that are being exercised by tests.
* **Healthy baseline:** 70–80% overall coverage sustained across your service scope is a strong indicator of a well-tested product. Teams with mature quality practices often maintain 80–85%+.
* **What to watch:** The trend matters more than any single snapshot. A stable or gradually improving number indicates testing is keeping pace with development. A slow decline (\~3–5% drop) over multiple weeks is an early warning that the codebase is growing faster than the test suite.
#### **Coverage by Service, Finding the Floor**
The App tab shows which services are pulling the overall number down. For an ongoing dashboard, track whether the lowest-covered services are improving over time or staying flat. A rising floor, where even the weakest services are gradually getting better, is one of the strongest signals of a maturing quality culture.
* **Red flag:** A service that sits consistently below 50% overall coverage while receiving active development is carrying disproportionate risk for the whole product.
#### **Recovery Time After Coverage Drops**
Coverage will dip during periods of intense development. What matters is how quickly it recovers. Teams with healthy testing habits typically see coverage bounce back within one sprint. A drop that persists across two or more sprints is a sign that test debt is accumulating faster than it's being paid down.
#### **Quarterly and Annual Trend**
Zoom out and compare the same rolling window quarter over quarter. A year-over-year improvement of 5–10% in overall coverage, sustained across services, is a strong indicator that quality engineering is becoming part of how the team works, not just something that happens before a release.
* **Industry context:** Organizations that treat coverage as an ongoing operational metric consistently outperform those that treat it as a pre-release checklist. The approach of "how is our coverage trending over time?" in addition to "are we covered enough to ship?" is what separates teams that find defects before users do from those that don't.
#### **Stakeholder Visibility**
An indirect but meaningful signal: how long does it take to answer "how are we doing on coverage?" With a persistent dashboard, the answer is always a link away. No report to pull, no data to aggregate. Teams that establish this kind of visibility typically spend less time preparing quality updates and more time acting on them.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.sealights.io/knowledgebase/guides/quality-improvement/coverage-analysis-playbooks/monitoring-ongoing-quality-as-a-team-dashboard.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.