Metrics For Developers 2026: Types, KPIs & Best Practices
Definition
A metric is a single, quantifiable measurement that tracks a specific attribute over time. Metrics are numerical, time-stamped, and machine-readable. They answer one question: how much or how many.
In software engineering specifically, a metric is a standard of measure of the degree to which a software system or process possesses some property, whether that’s request latency, error count, memory usage, or conversion rate.
Metrics are the raw ingredients. They tell you what is happening, not why. A metric that reads “error rate: 4.7%” is useful. But it doesn’t explain whether the errors come from a bad deployment, a downstream API failure, or a spike in malformed requests. That interpretation requires context, which is where analytics and observability come in.
If you’re building on serverless or edge runtimes and want to start collecting metrics from your application code, Distlang Metrics offers an API-first approach that works without agents or infrastructure setup.
Metrics vs. KPIs vs. Analytics
These three terms get tangled constantly. Here’s the clean distinction.
Metrics are the raw numbers. Response time, daily active users, error count, CPU utilization. They describe what’s happening in quantifiable terms.
KPIs (Key Performance Indicators) are a subset of metrics that have been chosen to represent strategic goals. Not all metrics are KPIs, but all KPIs are metrics. One practitioner on LinkedIn framed it well: KPIs are a suite of metrics with guardrails, so that an organization doesn’t over-optimize one metric at the expense of others.
Analytics is the interpretive layer, the process of discovering meaningful patterns in data. Dashboards display metrics. Analytics explains them.
| What it is | Question it answers | Example | |
|---|---|---|---|
| Metric | A raw data point | “What happened?” | 350ms average response time |
| KPI | A metric tied to a goal | “Are we on track?” | P95 latency under 500ms SLO |
| Analytics | Pattern interpretation | “Why and what next?” | Latency spikes correlate with cold starts after deploy |
KissMetrics captured the failure mode perfectly: “Metrics without analytics is the organizational equivalent of checking your speedometer every five seconds but never looking at the road. You know exactly how fast you are going. You have no idea whether you are heading in the right direction.”
Metrics in Observability: The Three Pillars
Modern observability rests on three pillars: metrics, logs, and traces. Each serves a different purpose.
Metrics tell you if there is a problem. They’re aggregated numerical data, things like latency percentiles, error rates, and throughput. They’re cheap to store and fast to query, which makes them ideal for dashboards and alerts.
Logs tell you why the problem happened. They’re detailed event records, typically text-based, that capture what a specific process did at a specific moment.
Traces show you where the problem is. They follow a single request as it flows through multiple services, revealing which hop introduced the delay or failure.
The relationship between monitoring and observability matters here too. Monitoring focuses on measuring values to detect effects, while observability aims to understand the cause of those effects. Organizations that adopt observability practices reduce their mean time to resolution (MTTR) by 50-70% compared to monitoring-only approaches.
For developers working with serverless architectures, metrics often serve as the first line of defense because logs and traces are harder to collect from ephemeral function instances.
Types of Metrics
The four standard metric types from Prometheus and OpenTelemetry have become the industry standard. Understanding which to use and when is the difference between useful instrumentation and noise.
Counters
A counter is a cumulative value that only goes up (or resets to zero on restart). Use it for things that accumulate: requests served, errors encountered, tasks completed.
Counters tell you how much has happened. You almost never look at a counter’s raw value. Instead, you compute rates: requests per second, errors per minute.
Gauges
A gauge represents a single value that can go up or down. Think of it as a thermometer. Current memory usage, active connections, queue depth, CPU percentage: these are all gauges.
Gauges tell you what’s happening right now. Unlike counters, the raw value of a gauge is meaningful on its own.
Histograms
Histograms record the distribution of values across predefined buckets. Rather than tracking just an average, a histogram captures how values are spread, letting you compute percentiles like p50, p95, and p99.
This is the right choice for latencies and request sizes, anywhere you care about the shape of the distribution rather than just the center. An average response time of 200ms hides the fact that 5% of your users might be waiting over 2 seconds.
For a walkthrough of instrumenting both counters and histograms in a real serverless handler, see instrumenting Cloudflare Workers.
Summaries
A summary is similar to a histogram but computes quantiles client-side, inside your application. The tradeoff: summaries cannot be aggregated across multiple instances. You lose the bucket-level visibility that histograms provide. The Prometheus project recommends histograms over summaries unless you must calculate quantiles in-app and don’t need aggregation.
Choosing the Right Type
A simple decision framework: if the team needs a rate, start with a counter. If the team needs current occupancy or resource usage, use a gauge. If the team needs percentiles or bucket-based SLO math, use a histogram.
When instrumenting with JavaScript, Distlang’s JavaScript metrics client supports counters and histograms out of the box with minimal setup code.
Metrics in Serverless and Edge Environments
This is where things get interesting, and where most generic metrics advice falls apart.
Traditional metrics collection uses a pull model. Prometheus, for example, scrapes HTTP endpoints on a schedule. This assumes your application is a long-running process with a stable network address. In serverless and edge environments, that assumption is wrong. Functions spin up, execute, and disappear in milliseconds. There’s nothing to scrape.
According to research from Baselime, 58% of serverless engineers say observability is their biggest challenge. The stateless, ephemeral nature of serverless applications makes them difficult to observe with standard monitoring approaches.
Push-Based Collection
Serverless metrics require a push-based model. Instead of waiting for a monitoring tool to pull data, the application pushes metrics directly to a collection endpoint before the function terminates. This is why tools built for serverless, including Distlang Metrics, use HTTP-based ingestion rather than agent-based scraping.
The Flush Problem
In a serverless handler, you typically have a narrow window to send data before the runtime freezes or destroys the execution context. On Cloudflare Workers, you use ctx.waitUntil() to keep the function alive long enough to flush metrics. On Vercel/Next.js, the equivalent is the after() API.
Getting this wrong means lost data. Getting it right means your metrics arrive reliably even from handlers that execute in under 50ms. For a detailed look at flush timing and buffering strategies, read about configuring flush behavior in short-lived handlers.
Delta Counters
One more serverless-specific concept: delta counters. Traditional counters report a cumulative total, and the monitoring system calculates the difference. But when each function invocation is independent with no shared state, you need counters that report the increment (the delta) rather than the total. Delta counters are well suited for the bursty traffic patterns typical in Function-as-a-Service environments.
Platform-specific quickstarts for Cloudflare Workers and Vercel/Next.js walk through the full setup including flush patterns.
Labels, Dimensions, and the Cardinality Trap
Labels (sometimes called dimensions or tags) are key-value pairs attached to a metric that let you slice data. A request counter might have labels for status_code, region, and endpoint. Labels are what make metrics queryable and useful.
But labels come with a cost that catches many developers off guard.
What Cardinality Means
Cardinality refers to the number of unique values in a dataset. In metrics terms, each unique combination of label values creates its own time series. If your request counter has labels for service (5 values), status_code (5 values), region (4 values), and endpoint (20 values), you get roughly 5 x 5 x 4 x 20 = 2,000 time series from a single metric definition.
That math escalates fast. Add a user_id label and you’ve gone from 2,000 series to potentially millions.
Why High Cardinality Hurts
High cardinality is not inherently bad, but it becomes problematic when it leads to increased storage costs, slow queries, and inefficient resource usage. As Grafana Labs put it bluntly: “Yes, high cardinality is bad.”
The serverless environment makes this worse. In auto-scaling environments, new instances spin up and get destroyed constantly. If each instance has unique identifiers in metric labels (instance IDs, container IDs), the number of unique series grows without bound.
Best Practices
The Prometheus project’s documentation states this clearly: do not use labels to store dimensions with high cardinality, such as user IDs, email addresses, or other unbounded sets of values.
Keep label values finite and small. Good labels: status_code, method, region. Bad labels: user_id, request_id, session_token.
Getting Started with Metrics
The fastest path to useful metrics is to start small. Instrument one counter and one histogram in a single handler.
A counter for total requests gives you throughput. A histogram for response duration gives you latency percentiles. Together, they answer the two most fundamental questions about any service: how busy is it, and how fast is it?
From there, add labels carefully (remembering the cardinality discussion above), expand to more endpoints, and build out your dashboard.
For a complete walkthrough from code to a working dashboard, the metrics quickstart guide covers every step.
If you want to go deeper into how payload batching and ingestion limits work, the guide on batching and payload format is worth reading before you scale up.
The overarching principle: track what you’ll act on. KissMetrics identified a common anti-pattern where teams track 50 metrics but can only articulate what they’d do differently based on changes in two or three of them. The rest is noise masquerading as signal.
Get started with Distlang Metrics on the free plan, which includes 500k rows per month and unlimited metric sets.
Related Terms
- Telemetry: The automated collection and transmission of data from remote systems.
- Observability: The ability to understand a system’s internal state from its external outputs (metrics, logs, traces).
- Monitoring: The practice of watching predefined metrics and alerting when thresholds are breached.
- Instrumentation: The code you add to your application to emit metrics, logs, or traces.
- Time-series database: A database optimized for storing and querying timestamped data points.
- Dashboard: A visual interface that displays metrics and their trends over time.
FAQ
What is the difference between a metric and a KPI?
A metric is any quantifiable data point, like page load time or signup count. A KPI is a metric that has been specifically chosen to measure progress toward a strategic goal. All KPIs are metrics, but most metrics are not KPIs.
Why can’t I use Prometheus in a serverless environment?
Prometheus uses a pull-based model where it scrapes endpoints on a schedule. Serverless functions are ephemeral, they don’t run long enough to be scraped. You need a push-based metrics system where the function sends data to a collection endpoint before terminating.
What metric type should I use for tracking request latency?
Use a histogram. Unlike a simple average (which hides outliers), a histogram captures the distribution of latency values and lets you compute percentiles like p50, p95, and p99. This gives you a much clearer picture of real user experience.
What is metric cardinality and why does it matter?
Cardinality is the number of unique time series created by a metric and its labels. High cardinality, often caused by adding labels with many unique values like user IDs, leads to storage bloat, slow queries, and higher costs. Keep label values bounded and finite.
How do I flush metrics from a Cloudflare Worker?
Use ctx.waitUntil() to extend the worker’s lifetime long enough to send metrics to your collection endpoint. Without this, the runtime may terminate before the HTTP request completes, and your data is lost.
What’s the difference between monitoring and observability?
Monitoring tells you when something went wrong and what the symptom is. Observability helps you understand why and how it happened. Monitoring is a subset of observability, focused on known failure modes, while observability helps you diagnose unknown problems.
How many metrics should I track?
Start with two or three that directly inform decisions, typically a request counter and a latency histogram. Add more only when you can articulate what action you’d take if the number changed. Tracking dozens of metrics without a plan for each one creates noise, not insight.
Are gauges or counters better for tracking active users?
Use a gauge. Active users is a value that goes up and down over time, which is exactly what gauges are designed for. Counters only increase, so they’re appropriate for cumulative totals like “total logins” rather than “current active sessions.”