canonical: https://jentic.com/apis/googleapis.com/google-cloud-monitoring

# Google Cloud Monitoring API

Cloud Monitoring is Google Cloud's observability service for collecting, querying, and alerting on metrics, with support for uptime checks and notification channels. The v3 API exposes time series, metric and monitored resource descriptors, alert policies, notification channels, groups, and uptime check IPs and configs. It pairs with Cloud Logging for full observability and supports Prometheus-compatible queries through monitored projects scoped to a Workspace.

## For AI agents

Read and write Google Cloud time series data, manage alert policies and notification channels, and configure uptime checks for any HTTP target.

## Scope

Does not handle log entry storage, distributed traces, or grouped error events - use for metrics, alert policies, notification channels, and uptime checks only.

## Capabilities

- Write custom time series points to Cloud Monitoring via collectdTimeSeries
- Manage alert policies that fire on threshold or absence conditions over time series
- Manage notification channels including email, SMS, PagerDuty, and webhook targets
- Configure uptime checks for HTTP, HTTPS, and TCP endpoints with regional checkers
- List metric and monitored resource descriptors available for query
- Group monitored resources by filter for fleet-wide policy and reporting
- Read uptime check IP ranges to allowlist Google's checkers in firewalls

## Use cases

### Production alerting on SLOs

Define alert policies that fire when latency, error rate, or availability metrics breach SLO thresholds, route them through notification channels for email, SMS, PagerDuty, or webhooks, and group related resources so a single policy covers an entire service. Setup typically takes a few hours for a new service.

Example prompt: Create an alertPolicy named api-error-rate that fires when metric.type=run.googleapis.com/request_count with response_code_class=5xx exceeds 5% over 10 minutes for service api-prod

### Synthetic uptime monitoring

Configure uptime checks against public HTTP, HTTPS, or TCP endpoints to detect outages from multiple regions, and pair them with alert policies that page on-call when a check fails. The uptimeCheckIps endpoint lists Google's checker addresses so firewalls and WAFs can allowlist them.

Example prompt: Create an uptimeCheckConfig for https://api.example.com/healthz with 60-second period and an alertPolicy that pages PagerDuty when the check fails for 5 minutes

### Custom metric ingestion

Write custom metrics to Cloud Monitoring so business KPIs and application internals appear in the same dashboards as infrastructure signals. The collectdTimeSeries endpoint accepts collectd-formatted points and the metric and monitored resource descriptor catalog lets you keep a clean type model for each KPI.

Example prompt: Write a collectdTimeSeries point for metric.type custom.googleapis.com/checkout/orders_per_minute with value 142 against the gce_instance resource with our prod VM ID

### Agent integration via Jentic

AI agents acting as on-call assistants can use Cloud Monitoring through Jentic to enumerate alert policies, page on incidents, and adjust uptime checks during incidents without holding the underlying OAuth refresh token in their prompt.

Example prompt: List alertPolicies in projects/acme and disable any whose displayName matches a pattern provided by the on-call runbook for the maintenance window

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v3/uptimeCheckIps | List Google's uptime checker IP ranges |
| DELETE | /v3/{+name} | Delete a Cloud Monitoring resource |
| GET | /v3/{+name}/alertPolicies | List alert policies in a project |
| POST | /v3/{+name}/collectdTimeSeries | Write collectd-formatted time series |
| GET | /v3/{+name}/groups | List monitored resource groups |
| GET | /v3/{+name}/metricDescriptors | List metric descriptors |
| GET | /v3/{+name}/monitoredResourceDescriptors | List monitored resource descriptors |
| GET | /v3/{+name}/notificationChannelDescriptors | List notification channel descriptors |

## Key resources

- **alertPolicies** — Create, list, update, and delete alert policies on time series
- **notificationChannels** — Manage email, SMS, PagerDuty, webhook, and other notification targets
- **uptimeCheckConfigs** — Configure synthetic HTTP, HTTPS, and TCP uptime checks
- **metricDescriptors** — List available metric types and their unit and label structure
- **monitoredResourceDescriptors** — List the monitored resource types that emit time series
- **groups** — Group monitored resources by filter for fleet-wide policy and reporting
- **uptimeCheckIps** — Read the IP ranges used by Google's uptime checkers

## Why Jentic

- **Setup:** Wiring the Cloud Monitoring API by hand means setting up Google OAuth 2.0 with the monitoring scope, minting bearer tokens, and tracking the v3 metric and alerting surface yourself against the monitoring.googleapis.com host. Through Jentic you install once, import the Cloud Monitoring API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Cloud Monitoring puts the project or resource name in the URL path (/v3/{+name}/...), so a rule can pin your agent to one project scope: it can list alert policies, groups, and metric descriptors there and nothing else. You choose the operations it may call, so destructive ones like deleting a resource are not included unless you add them.
- **Credential handling:** Your Google OAuth credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an alert policy' or 'list uptime checks', and Jentic returns the matching Cloud Monitoring operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Cloud Logging API** — Log entries paired with monitoring metrics for full observability
- **Error Reporting API** — Aggregated error events that often trigger Cloud Monitoring alert policies
- **Cloud Trace API** — Distributed traces that complement metrics for latency analysis

## FAQ

### What authentication does the Cloud Monitoring API use?

The API uses Google OAuth 2.0 with monitoring scopes such as https://www.googleapis.com/auth/monitoring and https://www.googleapis.com/auth/monitoring.write. Through Jentic the OAuth credentials are held in the encrypted vault and the agent only sees a scoped, short-lived bearer token.

### Can I create an alert policy from scratch through this API?

Yes. Post a new alertPolicy with a displayName, one or more conditions referencing metric filters, combiner logic, and the notificationChannels to call when the policy fires. The same shape is used to update an existing policy.

### What are the rate limits for the Cloud Monitoring API?

Read endpoints (alertPolicies, metricDescriptors, monitoredResourceDescriptors) and write endpoints have separate per-project quotas listed under the Cloud Monitoring service in the Cloud Console. Custom metric write quotas are higher than alert manipulation quotas; respect 429 backoff for ingestion-heavy workloads.

### How do I create an uptime check through Jentic?

Search Jentic for create uptime check google cloud, load the uptimeCheckConfigs create operation, and execute with the host, path, and period. Jentic injects the OAuth bearer token so the agent only constructs the check definition.

### Is the Cloud Monitoring API free?

Cloud Monitoring includes a free tier for Google Cloud metrics and a generous allowance for custom metrics; usage above that is billed per metric ingested and uptime check executions. See the Operations Suite pricing page for current rates.

### Why are there two monitoring versions in the catalog?

v1 is the dashboards-only surface for Cloud Monitoring dashboards. v3 is the main metrics, alerting, and uptime checks API. Use v3 for time series and alert policy work; v1 only when programmatically managing dashboards.

### Can I limit what my agent is allowed to do with the Cloud Monitoring API?

Yes. Because Jentic One is self-hosted, your own rules decide which Cloud Monitoring operations and credentials the agent may use. Since the API carries the project or resource name in the URL path (/v3/{+name}/...), you can pin the agent to a single project so it only lists and reads alert policies, groups, metric descriptors, and uptime checks there and nothing else. You choose the operations it may call, so destructive ones like deleting an alert policy or uptime check are excluded unless you explicitly add them.