Google Cloud Monitoring Overview: Metrics, Alerts, and Dashboards
At 2:14am a Cloud Run service started returning 503s. No user had reported it yet. A Cloud Monitoring alert fired at 2:15am. The on-call engineer rolled back the bad deployment by 2:22am. That is what monitoring is for: catching problems before your users do.
Google Cloud Monitoring is the metrics, alerting, dashboards, and uptime-check platform built into every GCP project. This page explains what it is, how it works, and what to configure first.
What Google Cloud Monitoring is
Cloud Monitoring is the metrics and alerting component of Google Cloud Observability, Google’s integrated suite of observability tools. It collects numeric measurements from your GCP services, stores them as time-series data, and gives you dashboards, alerting policies, and uptime checks to act on that data.
Most GCP services emit metrics automatically. When you deploy a Cloud Run service or create a Cloud SQL instance, Cloud Monitoring starts collecting request counts, error rates, latencies, and resource utilization with no setup required. You get baseline observability on day one.
For services that run inside virtual machines, you install the Ops Agent to collect system-level metrics like memory and disk usage. For custom application metrics, you write them via the Cloud Monitoring API or OpenTelemetry. If you use Prometheus, GCP’s Managed Service for Prometheus can ingest those metrics too.
If you are just getting started with observability in GCP, the monitoring your first project guide walks through the initial setup step by step.
Cloud Monitoring in simple terms
Think of it like a car’s instrument panel
The car’s computer automatically reports speed, fuel level, engine temperature, and oil pressure. You did not wire any of those sensors. You can glance at them at any time, set a warning light to trigger above a certain temperature, and review a history of how the engine has been running.
Cloud Monitoring works the same way. GCP services are the car. Metrics are the sensor readings. Dashboards are the instrument panel. Alerting policies are the warning lights. The difference is that instead of one car, you might be watching hundreds of services across multiple projects.
What Cloud Monitoring collects
Cloud Monitoring stores time-series data: a numeric value attached to a timestamp and a set of labels. A time series might represent “HTTP 5xx responses per second for Cloud Run service api-service in region us-central1.” Each data point has a value, a timestamp, and labels that identify what produced it.
See the full breakdown of metric types in the metrics in GCP guide. Here is where metrics come from:
Built-in GCP service metrics
Every managed GCP service (Cloud Run, Cloud SQL, GKE, Pub/Sub, Cloud Storage, and more) automatically emits metrics to Cloud Monitoring. No configuration required. These cover request rates, error rates, latency percentiles, connection counts, storage usage, and similar operational signals. They start flowing as soon as you use the service.
Ops Agent metrics for VMs
Compute Engine VMs emit CPU utilization metrics automatically, but metrics inside the VM require the Ops Agent. This is a lightweight agent you install on the VM. It uses the OpenTelemetry Collector under the hood and replaces the older Stackdriver agent. See the Compute Engine overview for context on when you need this.
VM memory and disk metrics are not automatic. CPU utilization is collected without an agent. Memory utilization and disk I/O are not. You must install the Ops Agent inside the VM to get those signals. This trips up a lot of teams during their first memory-related incident.
Custom metrics
Your application can report its own metrics via the Cloud Monitoring API or the OpenTelemetry SDK. Use this for business-level signals that GCP does not track automatically: order count per minute, checkout latency, queue depth, active WebSocket connections. Custom metrics use the custom.googleapis.com/ namespace.
Log-based metrics
If you have a log pattern that matters (authentication failures, a specific error code appearing in logs), you can turn it into a numeric metric using a log-based metric. Cloud Monitoring then treats it like any other metric: chart it, alert on it, include it in dashboards. This bridges Cloud Monitoring and Cloud Logging without a separate pipeline.
Prometheus metrics via Managed Service for Prometheus
If you already instrument your services with Prometheus, you do not need to rewrite your metrics code. GCP’s Managed Service for Prometheus (GMP) ingests Prometheus metrics and stores them in Cloud Monitoring’s backend. You can query them with PromQL in Metrics Explorer. This is particularly useful in GKE workloads where Prometheus is already standard.
How Cloud Monitoring works
The basic flow looks like this:
- A GCP service or your application emits telemetry data.
- Cloud Monitoring stores it as a time series, tagged with labels (like region, service name, or response code) and a monitored resource type (like
cloud_run_revisionorgce_instance). - You build charts in dashboards by querying time-series data. Filters on labels let you drill into specific services, regions, or response codes.
- Alerting policies watch one or more time series and fire when a condition is met. For example: error rate above 1% for five minutes. Notifications go to email, Slack, PagerDuty, or a Pub/Sub topic.
- Metrics scopes let a single monitoring project aggregate metrics from multiple GCP projects so you can see dev, staging, and prod in one place.
Labels are important because they let you slice data. An alert on “any Cloud Run revision with error rate above threshold” is more useful than an alert tied to a single fixed revision name. The creating alerts guide covers how to structure conditions and avoid noisy policies.
What you use it for
Cloud Monitoring is the right tool when you need to answer questions about numeric behavior over time. Common use cases:
- Watch Cloud Run error rate and latency. Set an alert when 5xx responses exceed a threshold. Track p99 latency over time to catch regressions. See the monitoring Cloud Run guide for the specific metrics that matter.
- Monitor VM CPU, memory, and disk. CPU is automatic. Memory and disk require the Ops Agent. Combine them into a single dashboard for each fleet of VMs.
- Track GKE workload health. GKE emits cluster-level and workload-level metrics automatically. See monitoring GKE for pod restarts, container CPU/memory, and node pressure signals.
- Detect endpoint outages. Uptime checks probe your public endpoints from multiple Google PoPs globally. A failed probe triggers an alert before users start complaining.
- Create SLO and error-budget alerts. Cloud Monitoring has built-in SLO support. Define a target like “99.5% of requests succeed over a 30-day rolling window” and alert on error-budget burn rate rather than raw error counts.
- Catch capacity or cost-related behavior early. Alert when a Pub/Sub subscription backlog grows beyond a threshold, or when Cloud SQL storage utilization approaches its limit. These signals are cheap to set up and save you from emergency scaling situations.
What to set up first in a new GCP project
If you are starting from zero, use this as your baseline. See monitoring your first project for the full walkthrough.
These six things take under an hour and cover the majority of production incidents most teams encounter:
- One dashboard covering your main service’s request rate, error rate, and latency. Use a prebuilt GCP service dashboard from Monitoring > Dashboards > Sample Library as a starting point.
- One error-rate alert. Fire when your service’s error rate exceeds a threshold for a sustained window. Five minutes is a reasonable starting point. Route it to email at minimum.
- One latency alert. Alert on p99 request latency. This catches performance regressions that error-rate alerts miss. A slow service that does not error is still broken.
- One uptime check for every public-facing endpoint. Configure it to alert after two consecutive failures. See uptime checks for how to set the check interval and failure threshold.
- Ops Agent on any Compute Engine VMs. Without it, you have no memory or disk metrics for those machines.
- One log-based metric if there is a specific error pattern in your logs that matters. If your app logs
payment_failed, turn that into a metric and alert on it. See log-based metrics for the setup.
Cloud Monitoring vs Cloud Logging vs Cloud Trace
All three are part of Google Cloud Observability. They answer different questions.
| Tool | What it stores | The question it answers |
|---|---|---|
| Cloud Monitoring | Numeric time-series metrics | What is my service doing right now, and how has it trended? |
| Cloud Logging | Log records (text, JSON) | What exactly happened during that event? |
| Cloud Trace | Distributed request traces | Why is this request slow, and which service is the bottleneck? |
In practice you start in Monitoring when an alert fires. The metric tells you something is wrong. You switch to Cloud Logging to read the actual log lines and find the error message. You open Cloud Trace when latency is the problem and you need to see where time is being spent across services.
These tools are integrated. An alert in Monitoring can include a direct link to a log query. A trace entry links to the log records for that specific request. You do not have to choose between them. Use all three together during an incident.
Metrics scopes explained
By default, opening Cloud Monitoring in a GCP project shows only that project’s metrics. A metrics scope expands that view. Every project has a metrics scope, and you can add other projects to it as monitored projects.
The standard pattern for teams with multiple environments is to create a dedicated monitoring project: a project that contains no workloads, only dashboards and alerts. You then add your actual environment projects to its metrics scope. All dashboards and alerting policies live in the monitoring project. Workloads run in their own projects.
A typical multi-environment setup
my-app-monitoring is the scoping project. It holds all dashboards and alerts. my-app-dev, my-app-staging, and my-app-prod are added as monitored projects. When you open Cloud Monitoring in my-app-monitoring you can filter any chart or alert by environment.
See GCP projects for how the project structure works and how IAM applies across projects.
The term “workspace” in older documentation refers to what is now called a metrics scope. The concept is the same.
Querying and dashboards
The primary way to query metrics in Cloud Monitoring is Metrics Explorer. You pick a resource type (like cloud_run_revision), select a metric (like request_count), and use filters and aggregations to narrow the data. Most beginners should start here. No query language required.
If you use Prometheus or prefer a more expressive syntax, you can query using PromQL in Metrics Explorer. This works especially well for GKE workloads where Prometheus instrumentation is already common.
Dashboards can be built in the console and exported to JSON or managed with Terraform using google_monitoring_dashboard. Once a dashboard is working in the console, exporting it to JSON and checking it into version control is a lightweight way to keep it reproducible. The dashboards in Cloud Monitoring guide covers that workflow.
Monitoring Query Language (MQL) is an older text-based query language you may see in existing dashboards and blog posts. It still works, but it is not the recommended path for new dashboards. Metrics Explorer with filters, or PromQL for Prometheus users, are the current practical approaches. If you encounter MQL in an existing resource, it will continue to function.
For programmatic access, reading time-series data from scripts or building custom tooling, use the Cloud Monitoring API. The google-cloud-monitoring Python client library and the Go client are well-maintained and cover the main use cases that the gcloud monitoring CLI does not.
CLI basics
# List all alerting policies in a project
gcloud monitoring policies list --project=my-app-prod
# List uptime checks
gcloud monitoring uptime list-configs --project=my-app-prod
# List dashboards
gcloud monitoring dashboards list --project=my-app-prodCommon beginner mistakes
- Treating monitoring as optional until an incident happens. By the time you need dashboards and alerts, it is too late to configure them. Add the baseline setup before your first production deploy, not after the first outage.
- Confusing metrics with logs. Metrics tell you that something is wrong (error rate spiked). Logs tell you what went wrong (the actual error message). They are separate products. Use Logs Explorer to investigate what Monitoring surfaces.
- Assuming VM memory metrics are automatic. CPU utilization for Compute Engine VMs is collected automatically. Memory utilization is not. You need the Ops Agent installed inside the VM.
- Creating alerts without labels or filters. An alert that fires for any revision in any region without filtering is hard to act on. Use labels to scope alerts to specific services or regions so the notification tells you exactly what broke.
- Waiting until production to define SLOs and alerts. Define your error rate and latency thresholds when you write the service. Retroactively tuning alert thresholds during an incident leads to poorly calibrated policies.
- Skipping the dedicated monitoring project pattern. Mixing dashboards and alerts into the same project as your workloads creates noisy cross-environment views. The monitoring project pattern costs nothing and pays off as soon as you have more than one environment.
Summary
- Cloud Monitoring is the metrics, alerting, dashboards, and uptime-check component of Google Cloud Observability
- Most GCP services emit metrics automatically with no agent or pipeline setup
- Compute Engine VMs need the Ops Agent for memory and disk metrics
- Metrics scopes let a single monitoring project aggregate data from multiple GCP projects
- Use Metrics Explorer or PromQL for querying. MQL is a legacy path.
- Cloud Monitoring (metrics) and Cloud Logging (logs) are separate products that work together
- Configure a baseline of one dashboard, error-rate alert, latency alert, and uptime check before going to production
Frequently asked questions
Is Cloud Monitoring the same as Stackdriver?
Stackdriver was the original name. Google rebranded the entire observability product family as Google Cloud Observability in 2020. Cloud Monitoring is the metrics, alerting, and dashboards component. You will still see "Stackdriver" in older Terraform resource names like google_monitoring_alert_policy. It is the same platform.
Do I need to install an agent to use Cloud Monitoring?
Not for most GCP services. Cloud Run, Cloud SQL, GKE, and other managed services emit metrics automatically. You only need the Ops Agent when you want system-level metrics from inside a Compute Engine VM: memory utilization and disk I/O are not collected without it.
What is a metrics scope?
A metrics scope defines which GCP projects a monitoring project can see. By default each project sees only its own metrics. You can create a dedicated monitoring project and add your dev, staging, and prod projects to its scope so all dashboards and alerts live in one place.
What is the difference between Cloud Monitoring and Cloud Logging?
Cloud Monitoring handles numeric time-series data: request rates, error percentages, CPU utilization. Cloud Logging handles log records, the actual text your application writes. They are separate products. Log-based metrics bridge them by turning log patterns into numeric metrics that Monitoring can alert on.
What should I configure first in a new GCP project?
Start with one dashboard covering your main service, one error-rate alert, one latency alert, and one uptime check for any public endpoint. If you are running Compute Engine VMs, install the Ops Agent so you get memory and disk metrics. That baseline catches most production problems.