Monitoring Your First GCP Project: Metrics, Logs, Alerts, and Audit Logs

Monitoring in plain English

Think of monitoring a GCP project like running a kitchen. The metrics are the display board showing how many orders are in flight and how long each one is taking. The logs are the order tickets: the exact record of what each table ordered, when it was sent, and what came back. The audit logs are the manager’s register: who opened the till, who changed the menu prices, and who unlocked the back door.

You need all three. The board tells you when service is slow. The tickets tell you which order went wrong. The register tells you who made the change that caused the problem.

• Metrics tell you how a system is behaving right now. A metric is a number that changes over time: CPU at 72%, 340 requests per minute, 3 errors in the last 60 seconds. Metrics are great for spotting trends, setting alerts, and building dashboards. They are not great for understanding exactly what went wrong.

• Logs tell you what happened. A log entry is a record of a specific event: a request came in, a function ran, an error was thrown with a stack trace. Logs give you the detail you need to diagnose a problem after metrics tell you something is wrong.

• Audit logs tell you who changed what. Audit logs record every IAM-controlled action in your project: who created a resource, who modified a policy, who deleted a bucket. They answer the question “how did we end up in this state?”

In practice: a metric alert fires, you open logs to investigate, and if it is a configuration or access issue you check audit logs to trace the cause. All three tools are in the same Console sidebar and are designed to work together.

Why monitoring matters in your first GCP project

It is tempting to skip observability setup on a small or experimental project. You know the code, you know the resources, you will notice if something goes wrong. In practice, this assumption breaks quickly for five reasons:

• Failures are invisible without alerts. A VM stuck at 100% CPU will not notify you. A Cloud Run service returning 500 errors will not send you a message. GCP does not proactively alert you about problems in your resources unless you configure alerting policies.

• Costs can escalate before you notice. A misconfigured service, a forgotten VM, or unexpected traffic can double your bill before the invoice arrives. A billing budget alert costs nothing to set up and catches these situations early. See how billing works in GCP for the full picture.

• Logs disappear after 30 days. If you need to investigate an incident, a compliance question, or a support case more than a month after the event, default retention means the data is gone. Exporting logs to Cloud Storage or BigQuery before that window closes requires a one-time configuration.

• Security events need an audit trail. Under the shared responsibility model, enabling and reviewing audit logs is a customer responsibility. Admin Activity logs are on by default. Data Access logs are not. If someone reads sensitive data in Cloud Storage or runs a BigQuery query against production data, that activity is only visible if you have enabled the right audit log type.

• Debugging without logs is guesswork. When a Cloud Run service starts returning 500 errors, the fastest path to the cause is Logs Explorer. The error message, stack trace, and request details are almost always there. Going straight to configuration changes before reading the logs adds unnecessary time to every incident.

The three core parts: metrics, logs, and audit logs

GCP organises observability into three distinct areas. Here is a quick overview of each before the deeper sections below.

Metrics in Cloud Monitoring

Cloud Monitoring collects numeric measurements over time from your GCP resources automatically. You do not need to install agents for basic infrastructure metrics. CPU usage, memory, disk I/O, network throughput, and request counts start flowing the moment you create a resource.

Access it via Monitoring in the Console left menu. The overview shows active incidents, uptime check results, and recent events. From here you can:

• View pre-built dashboards for Compute Engine, GKE, Cloud Run, and other services. See dashboards in Cloud Monitoring for how to build and customise your own.

• Browse the full list of available metrics in metrics in GCP, including what is collected automatically versus what requires instrumentation.
• Create alerting policies that notify you when a metric crosses a threshold for a sustained period.
• Set up uptime checks that regularly test whether a URL is responding from multiple geographic locations.

Setting up a useful alerting policy

Alerts fire when a metric condition is met for a specified duration. Getting the duration threshold right matters: set it too short and alerts fire on brief CPU spikes that resolve themselves. Set it too long and you miss real problems.

The five fields that matter most when configuring an alert:

• Metric: what to watch (e.g., compute.googleapis.com/instance/cpu/utilization)
• Filter: scope the alert to a specific resource, label, or service name
• Threshold: the value that triggers the alert (e.g., above 0.80 for CPU)
• Duration: how long the condition must persist before firing. 1–5 minutes prevents flapping on brief spikes.
• Notification channel: where to send the alert: email, PagerDuty, or Slack via Pub/Sub

# List existing alerting policies in a project
gcloud alpha monitoring policies list --project=my-project

# List available metric types for Compute Engine
gcloud monitoring metrics-descriptors list \
  --filter="metric.type:compute.googleapis.com" \
  --limit=20

Logs in Cloud Logging

Cloud Logging collects log entries from GCP services automatically. Compute Engine system logs, Cloud Run request logs, Cloud Functions execution logs, and Kubernetes application logs all stream here without any configuration. Your application can also write structured logs directly using client libraries, which makes searching and filtering far more powerful than plain text output.

Access logs via Logging > Logs Explorer. Logs Explorer lets you filter by resource type, severity, and time range through a visual interface, then refine further with the query language. Once you find the entries you need, you can save the query, use it in a log-based metric, or copy it into a runbook for the next engineer debugging the same issue.

When logs are most useful

Metrics tell you that something is wrong. Logs tell you why. Go to Logs Explorer when you need to:

• Find the error message or stack trace behind a failed request
• Understand the sequence of events that led to a failure
• Confirm whether a code path or feature is being reached at all
• Debug a Cloud Run service returning 500s. The logs almost always contain the cause. See troubleshooting Cloud Run container failures for the exact process.

Useful log query patterns

# Read recent ERROR and CRITICAL log entries across a project
gcloud logging read "severity>=ERROR" \
  --limit=20 \
  --project=my-project

# Find all logs from a Cloud Run service in the last hour
gcloud logging read \
  'resource.type="cloud_run_revision" AND resource.labels.service_name="my-api"' \
  --freshness=1h \
  --project=my-project

# Find logs containing a specific string (connection errors, exception names)
gcloud logging read \
  'textPayload:"connection refused"' \
  --limit=20

# Find WARNING and above from a specific VM instance
gcloud logging read \
  'resource.type="gce_instance" AND resource.labels.instance_id="1234567890" AND severity>=WARNING' \
  --limit=50 \
  --format=json

Audit logs in Google Cloud

Think of audit logs as the keycard access system for a secure building. Every door that opens, every badge that is swiped, every time someone enters a restricted area is recorded automatically. Admin Activity logs work the same way: every time someone changes a resource configuration or IAM policy, the event is written down with a timestamp and a name.

Cloud Audit Logs record every IAM-controlled action in your project. There are three types, and knowing which is which matters because their defaults are different. For a detailed breakdown of all GCP log types, see log types in GCP.

• Admin Activity logs: record changes to resource configuration and IAM policies: creating a VM, adding an IAM binding, deleting a bucket, modifying a firewall rule. Always enabled. Always free. Retained for 400 days. These are the logs you check when something unexpected has changed.

• Data Access logs: record reads and writes to data: reading a Cloud Storage object, running a BigQuery query, accessing a Cloud SQL row. Off by default. Enable them per service for any resource that handles sensitive data, PII, or credentials. They generate significant log volume on active services, so enable selectively.

• System Event logs: GCP-initiated actions like live VM migrations. Always enabled and free. Useful for understanding platform-side events that affect your resources without any human action.

When something breaks unexpectedly (a VM is gone, an IAM policy changed, a bucket is suddenly public), audit logs answer the question “who did this and when?”

# View recent Admin Activity audit logs
gcloud logging read \
  'logName="projects/my-project/logs/cloudaudit.googleapis.com%2Factivity"' \
  --limit=20

# Find who deleted a specific resource
gcloud logging read \
  'protoPayload.methodName:"delete" AND protoPayload.resourceName:"my-bucket"' \
  --limit=10 \
  --format="table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.methodName)"

How it works in a real first-project workflow

Here is the practical sequence most engineers follow once they have basic monitoring in place. This is not a formal incident response process. It is the day-to-day pattern for understanding what is happening in a new project.

1. Deploy or create a resource. Spin up a VM, deploy a Cloud Run service, or create a Cloud Storage bucket. Metrics start flowing immediately. No configuration needed.

2. Watch the key metrics for that resource. Open the pre-built dashboard for the service. For a VM, check CPU, memory, and disk. For Cloud Run, check request count, latency, and error rate. Establish what normal looks like before anything goes wrong.

3. Set one or two alert policies. Pick the metrics that matter most for your resource type. CPU utilisation for VMs. Error rate for HTTP services. Set a realistic threshold with a 5-minute duration window. See creating alerts in Cloud Monitoring for the setup walkthrough.

4. Open Logs Explorer when behaviour looks wrong. If a metric spikes or an alert fires, Logs Explorer is the first place to look. Filter to the relevant resource, set the time range to match the event, and look for ERROR or CRITICAL severity entries. For Cloud Run monitoring in particular, the structured request logs show status codes, latency, and container instance IDs for every request.

5. Check audit logs when configuration changes unexpectedly. If a resource disappears, a policy changes, or access suddenly fails, Admin Activity logs tell you which principal made the change and when. For access errors specifically, see troubleshooting permission denied errors and IAM access denied errors.

What to set up on day one

None of these take more than a few minutes. Together they give you meaningful visibility before anything goes wrong.

• Billing budget alert. Even if you are on the free tier, set a small budget alert (for example $5 or $10/month) to catch anything that escaped free tier limits. Go to Billing > Budgets & alerts. See billing budgets and alerts for the step-by-step setup.

• CPU or error-rate alert. Create one alerting policy on the metric that matters most for your resource type. CPU for VMs, error rate for HTTP services. Start with a 5-minute duration window to avoid false positives from brief spikes.

• Basic dashboard. Open the pre-built dashboard for your main service and bookmark it. Knowing where to look before an incident means you spend less time navigating when you need information quickly.

• Know how to open Logs Explorer. Go to Logging > Logs Explorer and run a simple query (for example, filter to your resource and set severity to ERROR). Doing this once means you can do it under pressure. The interface is straightforward but unfamiliar the first time.

• Enable Data Access audit logs for sensitive services. Admin Activity logs are already on. If you are using Cloud Storage, BigQuery, or Cloud SQL for anything beyond test data, go to IAM & Admin > Audit Logs and enable Data Access logging for those services.

• Decide whether you need log export. If you will need logs beyond 30 days for compliance, post-mortems, or long-term analysis, set up a log sink now. Go to Logging > Log Router, create a sink, and route logs to Cloud Storage or BigQuery. This runs automatically and cannot backfill logs that were already deleted.

When this page is most relevant

This page covers the basics of observability for a first GCP project. It is most directly useful when you are:

• Setting up your first Compute Engine VM and want to know when it is unhealthy
• Deploying a first Cloud Run service and need to watch request errors and latency
• Building a small internal tool that uses Cloud Storage, Cloud SQL, or Pub/Sub
• Working through a student lab or sandbox environment where costs and failures matter
• Joining a team and need to understand what monitoring is already in place

For more advanced observability topics (distributed tracing, GKE monitoring, log-based metrics, and production incident workflows), the Cloud Monitoring overview links to the full set of monitoring and observability pages.

Metrics vs logs vs audit logs: the difference at a glance

These three tools answer different questions. Knowing which to reach for first saves time when something goes wrong.

Example scenarios

Here are three realistic situations that beginners encounter, and which tool to reach for first in each.

Scenario 1: VM CPU is pinned high

A Cloud Monitoring alert fires: CPU utilisation on my-vm has been above 90% for 5 minutes. Start in the Compute Engine dashboard to confirm the spike is real and not a brief anomaly. Then open Logs Explorer, filter to that VM instance, and look for ERROR or CRITICAL entries in the same time window. Common causes include a runaway process, a cron job that kicked off unexpectedly, or a traffic spike the VM cannot handle. If you see no useful application logs, SSH into the VM and check running processes with top or ps aux to identify the CPU consumer directly.

Scenario 2: Cloud Run service returning 500 errors

Your Cloud Run service is returning HTTP 500s. Start in Logs Explorer. Filter to resource.type=“cloud_run_revision” and severity>=ERROR for the last 30 minutes. Cloud Run structured request logs include the HTTP status code, response time, and the container revision, so you can see whether the errors are from a specific revision or all revisions. The application logs (written by your code) usually contain the exception or error message. See Cloud Run container failed to start for a detailed debugging walkthrough.

Scenario 3: Cloud Storage bucket permissions changed unexpectedly

A bucket that was private is now returning public URLs, or a team member reports that they cannot access a bucket they previously could. This is an Admin Activity audit log question. Go to Logs Explorer and filter by:

• logName=“projects/my-project/logs/cloudaudit.googleapis.com%2Factivity”
• Add the bucket name to the filter
• Look for SetIamPolicy or storage.buckets.update method names

The audit log entry will show which principal made the change, from which IP address, and at what timestamp. If the change was not intentional, see troubleshooting authentication errors for next steps.

Log retention and export

Most application and resource logs are retained for 30 days by default. Admin Activity and System Event audit logs are retained for 400 days. If you need logs beyond their default retention period for compliance, long-term analysis, or incident investigation, set up a log sink that exports logs automatically to Cloud Storage or BigQuery.

Configure log sinks in Logging > Log Router. A sink filters log entries and writes matching entries to a destination bucket or dataset continuously. This is a one-time configuration. It does not backfill logs that were already deleted before the sink was created.