What Is Monitoring?

What Is Monitoring?

Monitoring is the continuous process of tracking the health, performance, availability, and behavior of a system. It helps teams see whether applications and infrastructure are working as expected and alerts them when something needs attention.

In software and IT environments, monitoring can track everything from API latency and application errors to CPU usage, database performance, Kubernetes workloads, website availability, and user experience.

The goal is simple: know what is happening in your systems before a small problem becomes a bigger one.

Monitoring usually works by collecting telemetry from applications and infrastructure, evaluating selected signals or conditions, and presenting the results through dashboards, alerts, reports, or automated workflows. Teams decide what matters, such as an error rate above 2%, a slow API, a full disk, or a failed checkout, and monitoring continuously watches for those conditions.

Monitoring at a Glance

Why Do We Need Monitoring?

Modern applications rarely run as a single process on a single server. A single user request may pass through a browser, CDN, API gateway, Kubernetes cluster, several microservices, a cache, a database, a message queue, and an external payment service before the user gets a response.

Without monitoring, teams often learn about problems from users. A checkout stops working, an API becomes slow, a disk fills up, or a database reaches its connection limit, but nobody notices until support tickets start arriving.

Monitoring gives teams an ongoing view of these systems. Instead of manually checking whether every service is healthy, engineers can continuously track important signals and receive alerts when something moves outside its expected range.

Monitoring is also useful when nothing is broken. Historical data helps teams understand normal behavior, investigate performance changes, plan capacity, measure reliability, and see how deployments or infrastructure changes affect production.

How Does Monitoring Work?

Monitoring usually involves five basic stages:

System → Data Collection → Evaluation → Visualization and Alerts → Response

The implementation can range from a simple uptime check to a monitoring platform collecting millions of measurements across thousands of services. The underlying idea remains the same: collect useful information, evaluate it continuously, and surface conditions that require attention.

1. Systems Generate Data

Applications and infrastructure continuously produce information about what they are doing. A server reports CPU and memory usage, an application records request latency and errors, a database reports active connections and query duration, and a web browser can provide information about page performance.

This information is often referred to as telemetry. Metrics, logs, traces, and other signals provide the raw data that monitoring systems use to understand what is happening.

2. Monitoring Collects the Data

Monitoring tools collect telemetry using agents, SDKs, integrations, APIs, exporters, browser scripts, collectors, custom metrics, and other mechanisms. Some systems push their data to the monitoring platform, while others expose information that the platform periodically retrieves.

The collection method depends on the technology being monitored. A cloud service may expose metrics through an API, while an application may be instrumented with OpenTelemetry and a Kubernetes cluster may provide metrics through agents and integrations.

3. The Data Is Evaluated

Collected data is continuously evaluated to determine whether the system is behaving normally. This can involve simple thresholds, comparisons with historical baselines, anomaly detection, SLO calculations, log patterns, synthetic test results, or combinations of several signals.

For example, a team might want to know when:

• API error rate exceeds 2%.
• p95 latency stays above 800 ms for five minutes.
• CPU utilization remains above 90%.
• A database has fewer than 10% of its connections available.
• A Kubernetes pod repeatedly restarts.
• A website fails a checkout test.
• Disk usage approaches its capacity limit.

The monitoring system repeatedly checks these conditions as new data arrives.

4. Dashboards and Alerts Surface Changes

Dashboards provide an ongoing view of service and infrastructure health. Engineers can use them to see current conditions, compare trends over time, and identify services or resources that require attention.

Alerts handle situations that should not depend on someone watching a dashboard. When an important condition is met, the monitoring platform can notify a team through email, Slack, Microsoft Teams, PagerDuty, incident-management systems, or other workflows.

5. Teams Investigate and Respond

An alert usually marks the beginning of an investigation rather than the end of one. Knowing that API latency has increased is useful, but an engineer still needs to understand which service, dependency, query, deployment, or resource caused the slowdown.

This is where monitoring increasingly overlaps with broader observability practices. Engineers can move from the affected metric into traces, logs, infrastructure data, database activity, or recent changes to determine what actually happened.

What Data Does Monitoring Use?

Monitoring is sometimes described as simply "watching metrics," but modern monitoring uses several forms of telemetry. Metrics remain important, but logs, traces, events, health checks, user data, and synthetic tests can all provide useful monitoring signals.

Metrics

Metrics are numerical measurements collected over time. They work particularly well for monitoring because they make changes, trends, thresholds, and comparisons easy to identify.

Common examples include:

• CPU utilization
• Memory usage
• Requests per second
• Error rate
• API latency
• Network throughput
• Disk usage
• Queue depth
• Active database connections

A metric such as CPU = 73% has limited meaning by itself. When recorded continuously, however, it can show whether CPU usage is stable, increasing, unusual for that time of day, or approaching a capacity limit.

Logs

Logs provide detailed records of individual events. Monitoring systems can search logs for patterns, error messages, security events, application exceptions, or changes that should trigger an alert.

For example, a team could monitor logs for repeated authentication failures or a sudden increase in database timeout messages. Logs are especially useful when a simple numerical metric cannot capture the condition being watched.

Traces

Distributed traces follow requests as they move between services. Trace-derived measurements can be used to monitor request rates, error rates, response times, service dependencies, and individual operations within distributed applications.

Traces become particularly useful after monitoring detects a problem. If p95 latency increases, engineers can examine slow traces to see which service or database operation contributed most to the delay.

Events

Events describe something that happened at a particular point in time, such as a deployment, configuration change, autoscaling action, container restart, or feature flag update. Monitoring these events alongside application health can make changes much easier to explain.

If error rate begins increasing immediately after a deployment, for example, the deployment event becomes useful context during the investigation.

Health Checks

Health checks test whether a service or component is reachable and functioning. A simple health check may periodically call an endpoint and verify that it returns the expected response.

These checks are useful for quickly identifying availability problems. More advanced synthetic tests can go further by performing complete user workflows instead of checking only whether a server responds.

What Are the Main Types of Monitoring?

Monitoring is a broad practice rather than a single technology. Different types of monitoring focus on different parts of the technology stack, and most production environments use several of them together.

Application Monitoring

Application monitoring tracks how software or application service behaves while it is running. It helps teams understand whether applications are available, responsive, processing requests successfully, and interacting correctly with their dependencies.

Typical application metrics include request rate, response time, error rate, exception count, endpoint performance, service dependencies, and database calls. Application Performance Monitoring, or APM, extends this by providing deeper visibility into transactions, traces, code paths, and service-level performance.

For example, monitoring may show that the checkout API's p95 latency increased from 300 milliseconds to two seconds. APM data can then help identify whether the slowdown comes from the checkout service itself, a database query, or an external payment API.

Infrastructure Monitoring

Infrastructure monitoring tracks the physical and virtual resources that applications are hosted on or depend on. This includes servers, virtual machines, containers, storage, operating systems, and other computing resources.

Common signals include CPU usage, memory utilization, disk capacity, disk I/O, load, network activity, host availability, and system processes. The objective is not simply to keep every metric low but to understand whether resource behavior could affect applications.

A server running at 85% CPU may be perfectly healthy under expected traffic. The same utilization with rapidly increasing latency and request queues tells a very different story.

Cloud Monitoring

Cloud monitoring tracks resources and managed services running on platforms such as AWS, Microsoft Azure, and Google Cloud. It can cover virtual machines, managed databases, object storage, serverless functions, load balancers, Kubernetes services, queues, and cloud APIs.

Cloud environments are dynamic, which makes continuous monitoring especially important. Resources can scale up and down automatically, containers can move between nodes, and serverless workloads may exist only while requests are being processed.

Network Monitoring

Network monitoring tracks whether systems can communicate reliably and efficiently. It can measure latency, packet loss, bandwidth utilization, connection errors, DNS performance, interface activity, and traffic between different parts of an environment.

Network problems can easily appear to be application problems. An API may become slow even though its code and CPU usage have not changed because communication with a database in another region has developed additional latency.

Database Monitoring

Database monitoring helps teams understand database health, workload, and performance. It can track query duration, active connections, throughput, locks, memory usage, cache performance, replication, storage, and slow queries.

This becomes especially useful during application incidents. A slow API may be caused by the application itself, but it may also originate from a query waiting on a lock, an exhausted connection pool, or a database running short of resources.

Kubernetes and Container Monitoring

Kubernetes monitoring tracks clusters, nodes, namespaces, workloads, pods, and containers. Because Kubernetes continuously schedules, scales, replaces, and moves workloads, monitoring only the underlying servers does not provide enough context.

Teams commonly watch pod health, CPU and memory consumption, container restarts, pending pods, node conditions, deployment status, resource requests and limits, and Kubernetes events. These signals can then be correlated with the applications running inside the cluster.

Log Monitoring

Log monitoring analyzes logs for errors, patterns, unusual activity, and events that require attention. Instead of manually searching millions of log entries, teams can create conditions that continuously identify relevant changes.

For example, a team could monitor for an increase in payment_timeout errors or repeated failed authentication attempts. Log monitoring can also generate metrics from recurring patterns, making trends easier to visualize.

Real User Monitoring

Real User Monitoring, or RUM, measures the experience of real people using a website or application. Data is collected from actual browser or application sessions rather than from backend servers alone.

RUM can show page load performance, Core Web Vitals, JavaScript errors, API failures, browser types, geographic performance, and user interactions. It helps identify problems that may not appear in backend monitoring.

For example, API latency might appear normal, while users on a specific browser version encounter a JavaScript error that prevents checkout from completing.

Synthetic Monitoring

Synthetic monitoring uses automated tests to simulate user actions at regular intervals. Instead of waiting for a real customer to attempt a login or checkout, a synthetic test can continuously perform that workflow and verify that it works.

Tests can range from simple HTTP uptime checks to multi-step browser journeys. A synthetic checkout test, for example, could open the website, search for a product, add it to the cart, begin checkout, and verify that each step succeeds.

Synthetic monitoring is useful even during periods when there are few or no real users. It can detect availability or functional failures before customers encounter them.

Serverless Monitoring

Serverless monitoring tracks applications running on services such as AWS Lambda and other function-based platforms. Since the underlying servers are largely managed by the cloud provider, teams focus more on function execution and service behavior.

Useful signals include invocation count, duration, cold starts, errors, timeouts, concurrency, memory consumption, and downstream dependencies. Distributed tracing can also help show how serverless functions interact with the rest of an application.

AI and LLM Monitoring

AI applications introduce additional things that need to be monitored beyond traditional CPU, latency, and error rates. Teams may need to track model calls, token usage, cost, model latency, tool calls, retries, failures, and feedback from users.

An AI application can return an HTTP 200 response yet still produce a poor result, so application health alone does not indicate whether the AI layer is behaving as expected. Current AI-monitoring approaches increasingly combine operational telemetry with model-specific performance, cost, and quality signals.

What Should You Monitor?

There is no universal list of metrics that every system needs. The right signals depend on what the service does, how users interact with it, and which types of failure would have a meaningful impact.

A useful starting point is to monitor several layers rather than focusing only on infrastructure.

Availability

First, determine whether the service is reachable and able to perform its basic job. Uptime checks, health endpoints, synthetic tests, and successful request measurements can provide this information.

Availability is important, but it should not be the only definition of health. A service that responds to requests but takes 15 seconds to do so may technically be available while still being unusable.

Latency

Latency shows how long requests or operations take. Percentiles such as p50, p95, and p99 are generally more useful than looking only at average latency because averages can hide a smaller number of very slow requests.

Latency should be monitored where users or downstream services actually experience it. This can include APIs, database queries, message processing, external dependencies, and frontend page loads.

Traffic

Traffic shows how much demand a system is handling. Depending on the workload, this may be requests per second, transactions per minute, queries, messages, active sessions, or another unit of useful work.

Traffic provides context for other signals. An increase in latency during a fivefold traffic spike suggests something different from the same latency increase when traffic has not changed.

Errors

Errors show whether requests or operations are succeeding. Monitoring should include explicit failures, such as HTTP 500 responses, as well as domain-specific failures, such as rejected payments or failed background jobs.

Whenever possible, error rate is more useful than error count alone. Five hundred failures mean very different things in a system handling one thousand requests versus one handling ten million.

Saturation

Saturation shows whether the system is approaching a resource or capacity limit. CPU and memory are common examples, but database connections, queue depth, thread pools, disk I/O, concurrency, and API rate limits may be better signals depending on the architecture.

Latency, traffic, errors, and saturation together form Google's widely used four golden signals framework for service monitoring. These signals provide a compact starting point for understanding service health without cluttering the first dashboard with every available metric.

Dependencies

Applications depend on databases, caches, message queues, APIs, cloud services, and third-party systems. Monitoring these dependencies can help teams distinguish between a problem within their own service and one caused by a downstream dependency.

For example, your application may remain healthy even if payment requests fail because the external payment provider becomes unavailable. Without dependency monitoring, the application error is visible, but its context is missing.

User Experience

Backend health should be connected with what users actually experience. Page loading, browser errors, mobile performance, API failures, and important workflows such as login or checkout all provide valuable user-facing signals.

This prevents teams from declaring a service healthy simply because its servers look healthy.

What Are Common Monitoring Methods?

Monitoring does not have to rely on one fixed threshold for every signal. Different techniques are appropriate for different types of systems and behavior.

Static Thresholds

A static threshold triggers when a measurement crosses a predefined value. Examples include disk usage above 90%, error rate above 5%, or fewer than five available database connections.

Static thresholds are simple and useful when the boundary between healthy and unhealthy behavior is well understood. They become less effective for metrics that naturally vary throughout the day or across workloads.

Dynamic Baselines

A dynamic baseline compares current behavior with what is normal for that system. Instead of assuming that 70% CPU is always bad, a monitoring system can identify when CPU usage is unusual compared with its historical pattern.

This can be particularly useful for systems with predictable daily or weekly changes.

Anomaly Detection

Anomaly detection looks for unusual behavior rather than only checking whether a fixed number has been crossed. It can help identify sudden changes, unexpected patterns, or combinations of signals that would be difficult to represent with a simple threshold.

An anomaly is not automatically an incident. The result still needs enough context to determine whether the change matters.

Health and Uptime Checks

Health checks periodically test whether a service can respond. They are simple but useful because they provide a direct answer to the question of whether an endpoint is reachable.

More advanced synthetic monitoring extends this idea by checking complete user journeys rather than a single endpoint.

SLO Monitoring

Service Level Objectives, or SLOs, measure reliability against a defined target over a period of time. Instead of alerting every time one request is slow, an SLO might track whether 99.9% of requests succeed during a 30-day window.

SLO monitoring helps teams focus on reliability from a user or service perspective rather than treating every individual metric fluctuation as equally important.

Is Monitoring Reactive or Proactive?

Monitoring is often described as reactive because many alerts are triggered after a problem begins. When a CPU threshold is crossed, errors increase, or a service becomes unavailable, the monitoring system notifies someone.

But monitoring does not have to wait for users to experience a failure. Capacity alerts can warn when disk space is running low, synthetic monitoring can detect a broken checkout before a customer does, and saturation metrics can show that a service is approaching its limit even while requests are still succeeding.

The more useful distinction is that monitoring continuously evaluates signals and conditions you have chosen to watch. Those conditions can represent problems that are already occurring or early indicators that something may soon become a problem.

Monitoring vs. Observability

Monitoring and observability overlap heavily, but they are not interchangeable.

Monitoring tracks selected signals and conditions to determine whether systems are healthy. Observability is the ability to investigate and understand system behavior using the telemetry those systems produce.

Imagine an alert that says checkout latency has increased above two seconds. Monitoring has done its job by detecting and surfacing the condition.

The engineer may not know why the checkout became slow. They might need to inspect distributed traces, database queries, application logs, Kubernetes changes, and recent deployments to discover that a new query is holding database connections for too long.

That second part is where observability becomes important.

Dash0 describes monitoring as tracking health and performance through predefined data and conditions, while observability provides the ability to ask broader questions about system behavior. Modern practice treats the two as complementary rather than competing approaches.

A simple way to remember the relationship is:

Telemetry provides the data. Monitoring tells you when something needs attention. Observability helps you understand what happened.

Example of Monitoring in a Real Application

Imagine an e-commerce application where customers suddenly begin experiencing slow checkout times.

A monitoring dashboard shows that:

• p95 checkout latency: increased from 450 ms to 2.8 seconds.
• Request traffic: remains close to normal.
• Error rate: remains below 1%.
• CPU usage: remains around 50%.
• Database connection utilization: increased from 60% to 97%.

This is already much more useful than receiving a generic "checkout is slow" report. Since traffic and CPU remain normal, the team can avoid spending time investigating a traffic spike or CPU shortage.

The alert leads engineers to inspect database-related traces. They find that a recently changed query is taking longer and holding database connections open, which is causing other requests to wait for available connections.

Monitoring detected the symptom and showed the relevant change. The surrounding telemetry then helped engineers identify the cause.

What Makes Monitoring Effective?

Good monitoring is not about collecting the largest number of metrics or building the biggest dashboard. It is about making important system behavior visible and making it clear when someone needs to act.

Monitor User Impact

Infrastructure measurements matter, but they should connect back to services and users. High CPU is less important than knowing whether that CPU usage is causing slow or failed requests.

Service-level signals such as latency, errors, availability, and successful user journeys often make better starting points.

Add Context

An alert saying CPU > 90% tells you very little about what is actually affected. Useful monitoring should include context such as the service, environment, host, Kubernetes cluster, region, version, or deployment involved.

The more context engineers receive with an alert, the less time they spend figuring out where to begin.

Correlate Signals

Metrics can show when performance changed, traces can reveal where the delay occurred, logs can explain the error, and deployment events can show what changed immediately beforehand.

Monitoring becomes far more useful when engineers can move between these signals without manually reconstructing the incident across unrelated tools. OpenTelemetry specifically supports correlation across telemetry signals by using shared context and consistent resource information.

Alert on Actionable Conditions

Not every unusual metric needs to wake someone up. Alerts should identify situations that require attention or action rather than simply report every fluctuation.

A dashboard can contain hundreds of measurements while the alerting strategy remains focused on conditions that meaningfully affect reliability, performance, capacity, or users.

Understand Normal Behavior

Monitoring becomes more useful when teams understand what normal looks like. Historical trends make it easier to distinguish expected daily changes from genuinely unusual behavior.

A traffic increase at 9 AM every weekday may be normal. The same increase at 3 AM could be worth investigating.

Common Monitoring Challenges

Monitoring can create its own problems when it is implemented without clear priorities. Collecting more data and adding more alerts does not automatically improve reliability.

Alert Fatigue

Alert fatigue happens when teams receive so many notifications that important ones become difficult to distinguish from noise. Repeated warnings about conditions that do not require action can eventually cause engineers to ignore the entire alert channel.

Alerts should therefore have clear ownership, useful context, and an expected response.

Too Many Dashboards

Dashboards are easy to create, which can lead to dozens of slightly different views that nobody regularly uses. Important information then becomes harder to find during an incident.

A smaller number of purpose-built views based on service health, users, or operational workflows is often more useful than displaying every available metric.

Monitoring the Wrong Metrics

A metric can be easy to collect without being useful. CPU utilization may look healthy while customers cannot complete checkout because a third-party service is failing.

Effective monitoring begins with what matters to the service and its users, then works downward into infrastructure and component-level signals.

Static Thresholds Everywhere

Static thresholds are appropriate for clear limits such as disk capacity, but they can create noise when applied to naturally variable signals. Traffic, latency, and workload patterns often change by time, region, service, or customer.

Baselines, percentiles, SLOs, and anomaly detection can sometimes represent this behavior more accurately.

Data Silos

Application metrics, logs, Kubernetes data, frontend performance, and traces may all live in separate tools. An engineer then receives an alert in one system and spends the next 30 minutes searching several others.

Shared identifiers and correlated telemetry reduce this friction by keeping the investigative path connected.

The Bottom Line

Monitoring is the continuous practice of tracking the health, availability, performance, and behavior of applications and infrastructure. It turns telemetry into operational awareness through metrics, dashboards, health checks, alerts, SLOs, and other monitoring techniques.

Different forms of monitoring provide different perspectives. Infrastructure monitoring shows whether computing resources are healthy, application monitoring tracks service behavior, RUM shows what real users experience, synthetic monitoring tests important workflows, and database or network monitoring provides deeper visibility into individual dependencies.

Monitoring works best when these perspectives are connected. A useful monitoring strategy does more than tell you that CPU is high or an endpoint returned an error; it helps you understand which service and users are affected and gives you enough context to decide what to investigate next.