What Is Cloud Monitoring? Types, Metrics, Tools, and Costs

Cloud monitoring is the continuous collection and analysis of metrics, logs, traces, and events from cloud infrastructure and applications, to know whether they are healthy, performing, secure, and within budget, and to tell someone when they are not. It used to mean a dashboard of CPU graphs. In 2026 it means at least eight distinct kinds of telemetry from a dozen possible tools, each billing on a different meter, adding up to a line that commonly reaches 5 to 10 percent of the cloud bill and on log-heavy estates becomes the second-largest item on it. Monitoring the cloud has become something that itself needs monitoring.

This explainer answers what cloud monitoring is, the eight types and what each covers, the metrics worth tracking, the native and third-party tools with their 2026 prices, worked cost examples, and why cost has become a monitored signal in its own right. Database and Kubernetes monitoring, the two most specialized kinds, have their own guides: database monitoring and Kubernetes monitoring.

The Eight Types of Cloud Monitoring

The Metrics That Matter

Google's four golden signals describe most services: latency, how long requests take; traffic, how many arrive; errors, how many fail; and saturation, how close the resource is to full. For infrastructure, the USE method tracks utilization, saturation, and errors per resource; for request-driven services, RED tracks rate, errors, and duration. The practical rule is to alert on symptoms users feel, latency and errors, and to use saturation and utilization to explain them. Cost belongs on the list as a fifth signal: a service with excellent golden signals and three times the capacity it needs is healthy and wasteful, and the second condition is also worth an alert.

What Cloud Monitoring Costs

Every tool bills on volume, and the meters differ. October 2026 list prices.

Worked Examples

Three estates, monthly, list prices, approximate.

Two conclusions hold across estates: logs are the line to manage first, because they bill per gigabyte on every tool and grow with verbosity rather than value; and native tools are two to four times cheaper for single-cloud estates that can accept their experience, which is the trade our Datadog pricing guide works through in detail.

Why Monitoring Bills Grow Faster Than Estates

• Logs at debug level in production. A service logging every request at full verbosity produces gigabytes a day that nobody reads and every tool bills.
• High-cardinality metrics. A custom metric tagged with user ID or request ID creates a series per value; CloudWatch bills each, Datadog bills beyond the per-host allowance.
• Retention by default. Everything kept at full fidelity for a year, when most queries touch the last week.
• Tool sprawl. Infrastructure in one tool, APM in another, logs in a third, each with its own per-host or per-GB meter and its own agent on every host.
• Nobody owns the line. Monitoring cost lands on the platform team's budget while every application team sets its own log levels and metrics.

The remedies: sample and tier logs (Infrequent Access, Basic, Auxiliary tiers exist for this), cap cardinality, set retention by value, consolidate tools, and attribute monitoring cost to the teams whose telemetry drives it. The AI-specific version of the same problem is in our guide to LLM observability.

Cost as a Monitored Signal

Cost behaves like every other signal: it has a baseline, it spikes when something changes, and the spike has a root cause that someone owns. Native cost tools report it daily, late, and without a cause. Treating spend as a monitored metric, with anomaly detection on seasonal baselines, budgets as thresholds, root cause from change history, and alerts routed to the owning team in the channel where their other alerts arrive, is what FinOps platforms add to the observability stack, and it is why the eighth type of monitoring increasingly sits beside the other seven.

How Opslyft Helps

Opslyft is the cost signal in that stack: continuous anomaly detection on allocated spend across AWS, Azure, GCP, Kubernetes, and Snowflake, with the resource, the change, and the owner attached to each alert and delivered to Slack beside the team's other monitoring, including the monitoring bill itself, which it attributes to the teams whose logs and metrics drive it. For the Kubernetes side of the telemetry it draws on, see our guide to Kubernetes monitoring.

The Bottom Line

Cloud monitoring is eight kinds of telemetry answering different questions, from whether the platform is up to whether the user is waiting to whether something is quietly costing money, and a bill that grows with volume on every tool that collects it. Track the golden signals, alert on symptoms, choose native tools for single-cloud estates and platforms for multi-cloud or deep APM, manage logs before anything else, and treat cost as a signal with a baseline and an owner. The specialized kinds are in our guides to database monitoring and Kubernetes monitoring; the leading platform's pricing is in our Datadog pricing guide.