The metrics any SaaS software development team needs to monitor

Every SaaS engineering team tracks metrics. The harder question is which ones actually help you ship better software, keep customers happy, and run a lean team without burning people out.

The wrong metrics send you in the wrong direction fast. Vanity metrics imposed from above, ones that don't help the team do its job or solve real problems, waste attention and erode trust in the numbers.

The right metrics share one characteristic: your team uses them actively. They help people prioritize, unblock work, and make calls with confidence, not just report upward.

Monitor the right ones and you'll improve customer experience, accelerate time to market, and make team management easier. Here's what that looks like across five areas.

Development process metrics

These three metrics tell you how work flows through your team, where it stalls, and how predictable your output actually is.

• WIP (work in progress) limits: WIP limits come from lean and Kanban thinking. They cap how many items can sit in any given stage of your production cycle, such as code review or QA. When you monitor WIP, you can spot bottlenecks before they compound. If your team is writing new code faster than reviews are clearing, the answer isn't more code, it's rallying around what's already written and getting it shipped.

• Cycle time: Cycle time is how long a task takes from start to done. Track it per process step or per team. Monitoring cycle time on each user story, for example, tells you how long code reviews or feature verification actually take on average, not how long you think they take. Read more about why Cycle time is important.

• Velocity: Velocity is one of the most common metrics scrum teams use. It measures how many story points a team completes per sprint, which helps with planning and predictability. One caution: using velocity to evaluate individual developer performance backfires. It changes the incentive and degrades the signal.

Quality control metrics

Shipping fast matters. Shipping broken code costs more than the time you saved. These metrics keep quality visible.

• Number of bugs: An agile team needs to know its bug pool at all times. It's easy, and sometimes expected by stakeholders, to chase feature work and ignore accumulating defects. Don't. Segment bugs by component or service, severity (critical, major, normal), and type (performance, usability, security). That segmentation tells you where the clusters are and where to focus. Set a defect threshold. When you cross it, pause feature development and fix. Ideally, each sprint opens with clearing recently introduced bugs before new work begins. Some teams enforce a zero known bug policy.

• Code smells count: Code smells are structures in the code that violate fundamental design principles and degrade quality. Static analysis tools like SpotBugs and Lint catch anti-patterns and syntactical defects early, sometimes as the developer types. That makes them among the cheapest quality interventions available. Define rules that fit your context; default rules are often noisy. If you're working with legacy code or introducing these tools for the first time, zero issues may not be realistic. Set a target and reduce the count over time.

• Code coverage: Test coverage measures how many lines or branches in your code are exercised by automated tests. High coverage only means something if the tests are well-written. It's possible to have 100% coverage and still ship bugs. If you're at 0%, you have a problem. If you're at 100%, don't assume you're safe. Coverage is a floor, not a ceiling. Here's a great post worth reading on this.

• Test failures: Track failure counts segmented by test or suite. Intermittent failures, the flaky ones that pass sometimes and fail other times, are a persistent drain. Find which 20% of tests generate 80% of failures and fix the root cause, whether that's flaky test code, product code, or environmental instability.

• Test suite cycle time: Tests exist to give developers fast feedback. If your test suite takes hours to run and your goal is multiple production deploys per day, those two things are in direct conflict. Track test execution time. Treat slow suites as a problem worth solving, not a background inconvenience.

Software delivery performance metrics

The following four metrics come from the Accelerate State of DevOps report by Google. We keep the descriptions brief here, but the full report is worth reading. It includes a self-assessment against four performance tiers: elite, high, medium, and low. Measuring your team against those benchmarks clarifies the gap between where you are and where high-performing teams operate.

The above figure is from the Accelerate State of DevOps report 2019.

These DORA metrics (Deployment Frequency, Lead Time for Changes, Time to Restore Service, and Change Failure Rate) are the clearest signal of whether your delivery pipeline is helping or hurting the business. Elite teams deploy on demand and restore service in under an hour. Knowing where you stand tells you what to fix first.

Production metrics

SLI and SLO

A service level indicator (SLI) is a numerical measurement of service health. It tells you whether you're meeting your service level objective (SLO). Read more about SLI, SLO, and SLA.

SLIs are the modern replacement for simple uptime monitoring. In a microservices architecture, a service rarely goes completely down. It degrades. Tracking up/down misses that. Depending on your service, an SLI might measure response time, error rate, or job execution lag. When an SLI drops below a set threshold, the team responds. A sharp drop with customer-facing impact triggers an incident response. A slower, sustained drop may mean pulling engineering capacity away from feature work to address the root cause.

SLIs are your highest-level signal for each service. Beneath them, you still need telemetry: CPU and memory usage, connection pool health, and similar indicators that explain why the SLI moved.

Cloud cost

Monitoring production cost per service and per customer is non-negotiable. Cloud bills grow quietly and quickly. Without the right tooling, you can spend a lot before you understand where it's going. Break down spending by service, region, and other relevant dimensions. The goal is to keep spending proportional to business growth, not running ahead of it.

Toil cost

Toil is manual, repetitive, automatable, reactive work. As your team and infrastructure scale, toil grows unless you actively track and eliminate it. Think of toil the way a feature team thinks about technical debt: ignore it long enough and it crowds out everything else. Define your team's toil capacity. Systematically bring it down.

Product health metrics

Every SaaS product has major user flows. These are the paths users take to accomplish something important, and they have a direct impact on experience and revenue. You need to know, in close to real time, how each production release affects those flows.

Two examples that are almost always critical:

• Trial sign-ups: A SaaS product typically sees a consistent volume of new trial sign-ups. Know your baseline. Flag unusual drops or spikes quickly. An anomaly here means something changed at the top of your funnel.

• Payment errors: Credit card declines happen. But all payment flow errors should be logged by type and monitored over time. An unusual pattern in payment failures means revenue is being lost right now.

Beyond those, ask yourself: what are the first goals a trial user has to accomplish? What 20% of your functionality is responsible for 80% of customer value? Those are the flows worth monitoring closely, because a degraded experience there is a business problem, not just a technical one.

---

These metrics have helped us scale our team, improve the product, and keep customers in a better position. The goal isn't a longer dashboard. It's the right signals, visible to the right people, without anyone having to dig for them. What metrics is your team tracking?