Cloud Monitoring

Create a custom metric, write a point and read it back from the emulator.

Plan: Pro56 of 56 methods implemented16Known differences

Metrics and alerts are local: only a subset of threshold evaluation is supported, and external notification delivery and uptime probes aren't run.

Example checked on Vera 1.2.2, 8 November 2026. Each coverage note names its own evidence and date.

Connect

Cloud Monitoring needs Pro or an active Pro trial. Activate your license key and start the emulator with the Vera launcher, as in Activate Pro, then run these in a terminal of their own. They use Google Cloud’s address on your machine.

export VERA_ENDPOINT="http://localhost:8081"
BASE="$VERA_ENDPOINT/_gcp/monitoring/v3/projects/example-project"

Requests go to $VERA_ENDPOINT/_gcp/monitoring/v3/, with no Authorization header. No Google Cloud credentials or existing Google Cloud project are needed. This page uses REST: the example needs curl, plus python3 to generate current timestamps and the request JSON. No gcloud command group has been tested against the emulator’s Monitoring API.

Example

Create a metric descriptor, write one point with the value 7, and read it back. The descriptor’s type, custom.googleapis.com/docs_audit/count, is the identifier the other requests use.

curl --fail --silent --show-error -X POST "$BASE/metricDescriptors" \
  -H 'Content-Type: application/json' \
  -d '{"type":"custom.googleapis.com/docs_audit/count","metricKind":"GAUGE","valueType":"INT64","unit":"1","displayName":"Docs audit count"}'

curl --fail --silent --show-error \
  "$BASE/metricDescriptors/custom.googleapis.com/docs_audit/count"

Both requests return the descriptor. These are selected fields: the whole response has more, including a list of monitored-resource types.

{
  "name": "projects/example-project/metricDescriptors/custom.googleapis.com/docs_audit/count",
  "type": "custom.googleapis.com/docs_audit/count",
  "metricKind": "GAUGE",
  "valueType": "INT64",
  "unit": "1",
  "displayName": "Docs audit count"
}

Next, generate the time-series request and a matching query interval. The Python script writes the point, timestamped now, to metric-point.json, and an interval covering the last hour to metric-interval.json. Then write the point and read it back:

python3 - <<'PY'
import datetime, json
now = datetime.datetime.now(datetime.timezone.utc)
stamp = now.isoformat().replace('+00:00', 'Z')
start = (now - datetime.timedelta(hours=1)).isoformat().replace('+00:00', 'Z')
point = {
    'metric': {'type': 'custom.googleapis.com/docs_audit/count'},
    'resource': {'type': 'global', 'labels': {'project_id': 'example-project'}},
    'points': [{'interval': {'endTime': stamp}, 'value': {'int64Value': '7'}}],
}
with open('metric-point.json', 'w') as f:
    json.dump({'timeSeries': [point]}, f)
with open('metric-interval.json', 'w') as f:
    json.dump({'start': start, 'end': stamp}, f)
PY

curl --fail --silent --show-error -X POST "$BASE/timeSeries" \
  -H 'Content-Type: application/json' -d @metric-point.json

START="$(python3 -c 'import json; print(json.load(open("metric-interval.json"))["start"])')"
END="$(python3 -c 'import json; print(json.load(open("metric-interval.json"))["end"])')"

curl --fail --silent --show-error --get "$BASE/timeSeries" \
  --data-urlencode 'filter=metric.type="custom.googleapis.com/docs_audit/count"' \
  --data-urlencode "interval.startTime=$START" \
  --data-urlencode "interval.endTime=$END"

The write answers {}. The read returns a timeSeries array with the custom metric, the global resource and the point you wrote. These are selected fields: the point also carries the timestamp the script generated, which differs on every run.

{
  "timeSeries": [
    {
      "metric": { "type": "custom.googleapis.com/docs_audit/count" },
      "resource": { "type": "global" },
      "points": [{ "value": { "int64Value": "7" } }]
    }
  ]
}

To clean up, delete the custom descriptor and the two files. Deleting this descriptor also removes its stored project time-series points; this was checked on Vera 1.2.0-rc.3, on 6 November 2026.

curl --fail --silent --show-error -X DELETE \
  "$BASE/metricDescriptors/custom.googleapis.com/docs_audit/count"
rm metric-point.json metric-interval.json

Supported features

Custom metric descriptors: create, read and delete them, with the GAUGE kind and INT64 values shown above.
Time-series points: write points to a custom metric yourself, and read them back with a metric type filter and a time interval.
Monitored-resource types are listed in descriptor responses. That’s metadata: it doesn’t mean those resources are running or being monitored.
Threshold alerts: a supported numeric threshold can open an alert when a local point is written. Policies and alerts can be read back; evaluation is limited to the subset described under Limitations. On Vera 1.2.0-rc.3, on 6 November 2026, writing the value 7 to a metric with a greater-than-5 threshold opened an alert.
Local metadata: groups, notification channels, uptime-check configurations, monitored services and SLO definitions can be stored. Storing them doesn’t start real monitoring, probes or applications. The API coverage notes say which were checked on Vera 1.2.0-rc.3 and which come from a review of the Vera 1.2.0 source.

Limitations

The main limits are below. A few more apply to every service, and the API coverage notes cover smaller differences.

No Google Cloud telemetry. Writing a point doesn’t collect measurements from a VM, container or cloud account: the example supplies its value itself. Source inspection also confirms a small set of metrics derived from local emulator state, such as Pub/Sub backlog and Cloud Storage object counts. These aren’t measurements from Google Cloud, and they aren’t sampled as complete history.
Partial alert evaluation. Supported threshold conditions are evaluated as points are written. Each condition is evaluated on its own: condition combiners, absence detection and MQL or PromQL conditions aren’t fully evaluated. Snoozes suppress local notifications, but they don’t stop alerts from opening.
Notifications and probes stay local. Source inspection confirms that supported alerts can publish to local Pub/Sub, when configured with the required permissions. Email, SMS and other external channels aren’t contacted, verification codes aren’t delivered, and uptime-check configurations don’t run network probes.
Limited query support. Monitoring Query Language supports only a simple fetch, such as fetch global | metric '<type>' with the metric type in single quotes. On Vera 1.2.0-rc.3, an aggregation pipeline and a type in double quotes answered 501, and an accepted | within 1s suffix didn’t filter out a two-hour-old point. Source inspection also shows that collectd requests don’t become project time-series points, and that folder and organization time-series lists don’t aggregate project metrics.
No durability or real timing. Data isn’t guaranteed to last, and timing isn’t Google Cloud’s. Treat it as disposable, as described in Running the emulator.

API coverage

Every method in Google Cloud's published v3 API (discovery document, revision 20261022), and whether the emulator implements it. Findings without a date are from testing on 5 November 2026. Local observation notes without a build or date are from Vera 1.2.0 preview, on 5 November 2026. Methods not checked earlier were assessed by a review of the Vera 1.2.0 source on 6 November 2026: source inspection describes an implementation and its known limits, not a successful run in a release build or a comparison with Google Cloud. Failures in a tested build are marked separately, and each note from this review names its evidence and date. What the statuses mean

projects.alertPolicies

5 of 5 implemented · 3 known differences

Method	Status	Notes
create	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the policy, but evaluates only supported numeric threshold conditions with ANDed equality selectors and supported aligners. Each condition is evaluated on its own; combiners, absence, MQL, PromQL and other condition types aren't fully evaluated. Only local Pub/Sub channels receive notifications. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — a policy with one `COMPARISON_GT` threshold of 5 on a custom metric answered HTTP 200. Writing a point with the value 7 then made listing alerts return an `OPEN` alert for it.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — deletes a local alert-policy definition. Supported threshold conditions are evaluated as points are written, not on Cloud Monitoring's full schedule. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — deleting an alert policy answered HTTP 200 with `{}`.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads a local alert-policy definition. Supported threshold conditions are evaluated as points are written, not on Cloud Monitoring's full schedule.
list	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists and filters stored policies with paging, but after validating `orderBy` it sorts by resource name, whatever order is requested.
patch	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — updates the policy, but evaluates only supported numeric threshold conditions with ANDed equality selectors and supported aligners. Each condition is evaluated on its own; combiners, absence, MQL, PromQL and other condition types aren't fully evaluated. Only local Pub/Sub channels receive notifications.

projects.alerts

2 of 2 implemented

Method	Status	Notes
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads a local alert record from the limited threshold evaluator. It doesn't reproduce all of Cloud Monitoring's incident behavior.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists, with paging, local alert records from the limited threshold evaluator. They don't reproduce all of Cloud Monitoring's incident behavior. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — after a point above a policy's threshold was written, listing alerts answered HTTP 200 with one `OPEN` alert for that policy.

projects.collectdTimeSeries

1 of 1 implemented · 1 known difference

Method	Status	Notes
create	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — accepts the request and stores a separate record, but collectd payloads don't become readable project time-series points, and their alerts aren't evaluated. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — a request with an empty `collectdPayloads` list answered HTTP 200 with `{}`, which shows only that the request is accepted.

projects.groups

5 of 5 implemented

Method	Status	Notes
create	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — creates and stores a local monitored-group definition and its hierarchy, honoring `validateOnly`. Membership covers a limited set of local resources, not every resource type in the descriptor catalog.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — deletes a local monitored-group definition. Membership covers a limited set of local resources, not every resource type in the descriptor catalog.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads a local monitored-group definition and its hierarchy. Membership covers a limited set of local resources, not every resource type in the descriptor catalog.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists local monitored-group definitions with paging. Membership covers a limited set of local resources, not every resource type in the descriptor catalog.
update	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — updates a local monitored-group definition and its hierarchy, honoring `validateOnly`. Membership covers a limited set of local resources, not every resource type in the descriptor catalog.

projects.groups.members

1 of 1 implemented · 1 known difference

Method	Status	Notes
list	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — computes current membership from loaded Compute Engine VMs, Cloud Storage buckets, Pub/Sub topics and Cloud SQL instances, with a limited AND-comparison filter. It doesn't provide historical membership for the requested interval.

projects.metricDescriptors

4 of 4 implemented

Method	Status	Notes
create	Implemented	Local observation: Created a custom `GAUGE` descriptor with `INT64` values in Vera 1.2.0 preview.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — deleting a custom metric descriptor also removes its stored project time-series points. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — a time-series query that had returned a custom metric's point answered HTTP 200 with an empty response after the descriptor was deleted.
get	Implemented	Local observation: Read the custom descriptor back by its type in Vera 1.2.0 preview.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists stored custom descriptors, local log-based metric descriptors and a bundled catalog of Google metric descriptors. Being in the catalog doesn't mean a metric is collected automatically.

projects.monitoredResourceDescriptors

2 of 2 implemented

Method	Status	Notes
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads the bundled descriptor catalog, plus local descriptor records where they apply. These are metadata snapshots, not a live Google Cloud inventory.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists the bundled descriptor catalog with paging, plus local descriptor records where they apply. These are metadata snapshots, not a live Google Cloud inventory.

projects.notificationChannelDescriptors

2 of 2 implemented

Method	Status	Notes
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads the bundled descriptor catalog, plus local descriptor records where they apply. These are metadata snapshots, not a live Google Cloud inventory.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists the bundled descriptor catalog with paging, plus local descriptor records where they apply. These are metadata snapshots, not a live Google Cloud inventory.

projects.notificationChannels

8 of 8 implemented · 4 known differences

Method	Status	Notes
create	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — creates and stores a local notification channel. Local Pub/Sub channels can receive supported alerts; email, SMS and other external providers aren't contacted. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — creating an `email` channel answered HTTP 200 and returned it, enabled.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — deletes a local notification channel. Local Pub/Sub channels can receive supported alerts; email, SMS and other external providers aren't contacted. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — deleting a notification channel answered HTTP 200 with `{}`.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads a local notification channel. Local Pub/Sub channels can receive supported alerts; email, SMS and other external providers aren't contacted.
getVerificationCode	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — requires an already `VERIFIED` channel and stores a new code locally. The ordinary send-and-verify flow can't obtain the first code, because none is delivered, and `verify` doesn't enforce code expiry. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — for a new, unverified `email` channel it answered HTTP 400 `FAILED_PRECONDITION`, saying a code can be retrieved only for a verified channel.
list	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists and filters stored channels with paging, but after validating `orderBy` it sorts by resource name, whatever order is requested.
patch	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — updates a local notification channel. Local Pub/Sub channels can receive supported alerts; email, SMS and other external providers aren't contacted.
sendVerificationCode	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns success and records a random code locally, but doesn't deliver it to the channel or return it to the caller, so this isn't a usable email or SMS verification flow. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — for a new `email` channel it answered HTTP 200 with `{}`.
verify	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — checks only whether the code is in the channel's local code store, then marks the channel `VERIFIED`. It doesn't enforce expiry or check for an equivalent channel identity, and sending a code doesn't deliver one. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — verifying a new `email` channel with a code that was never issued answered HTTP 400 `INVALID_ARGUMENT`.

projects.snoozes

4 of 4 implemented · 2 known differences

Method	Status	Notes
create	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores a snooze that suppresses local Pub/Sub notifications for the named policies during its interval, but doesn't stop alerts from opening; `criteria.filter` isn't applied to the suppression.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads a local snooze. An active snooze suppresses local Pub/Sub notifications for its policies during its interval, while alerts still open and close.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists local snoozes with paging. An active snooze suppresses local Pub/Sub notifications for its policies during its interval, while alerts still open and close.
patch	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores a snooze that suppresses local Pub/Sub notifications for the named policies during its interval, but doesn't stop alerts from opening; `criteria.filter` isn't applied to the suppression.

projects.timeSeries

4 of 4 implemented · 1 known difference

Method	Status	Notes
create	Implemented	Local observation: Wrote one `INT64` point to a custom metric on the `global` resource in Vera 1.2.0 preview. It answered `{}`.
createService	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — writes service-metric time series to the local store, rejecting `custom.googleapis.com` and `external.googleapis.com` metric types. It doesn't collect metrics from running services.
list	Implemented	Local observation: Returned the written point for a `metric.type` filter and a one-hour interval in Vera 1.2.0 preview. Other filters and aggregations weren't checked.
query	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — only a simple `fetch <resource> \| metric '<type>'` or `fetch <resource>::<type>` query reads stored local series. Other MQL pipelines return HTTP 501, and a `within` suffix is accepted but ignored, so it doesn't limit the point interval. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — with the metric type in single quotes, a simple fetch answered HTTP 200 with the stored point, and adding `\| within 1s` returned the same two-hour-old point. A `group_by` pipeline answered HTTP 501 `UNIMPLEMENTED`, as did the simple fetch with the type in double quotes.

projects.uptimeCheckConfigs

5 of 5 implemented · 2 known differences

Method	Status	Notes
create	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — creates and stores a local uptime-check configuration. The emulator schedules no network probes and produces no checker measurements.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — deletes a local uptime-check configuration. The emulator schedules no network probes and produces no checker measurements.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads a local uptime-check configuration. The emulator schedules no network probes and produces no checker measurements.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists local uptime-check configurations with paging. The emulator schedules no network probes and produces no checker measurements.
patch	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — updates a local uptime-check configuration. The emulator schedules no network probes and produces no checker measurements.

services

5 of 5 implemented

Method	Status	Notes
create	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — creates and stores a local monitored-service definition, with a canonical project-number resource name. A definition doesn't create a running application or measure its requests.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — deletes a local monitored-service definition. A definition doesn't create a running application or measure its requests.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads a local monitored-service definition, with its canonical project-number resource name. A definition doesn't create a running application or measure its requests.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists local monitored-service definitions with paging. A definition doesn't create a running application or measure its requests.
patch	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — updates a local monitored-service definition, with its canonical project-number resource name. A definition doesn't create a running application or measure its requests.

services.serviceLevelObjectives

5 of 5 implemented

Method	Status	Notes
create	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — creates and stores a local SLO definition under an existing monitored service, validating its goal, period and indicator. The emulator doesn't compute SLO compliance or burn rates.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — deletes a local SLO definition under an existing monitored service. The emulator doesn't compute SLO compliance or burn rates.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads a local SLO definition under an existing monitored service. The emulator doesn't compute SLO compliance or burn rates.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists, with paging, the local SLO definitions under an existing monitored service. The emulator doesn't compute SLO compliance or burn rates.
patch	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — updates a local SLO definition under an existing monitored service, validating its goal, period and indicator. The emulator doesn't compute SLO compliance or burn rates.

uptimeCheckIps

1 of 1 implemented

Method	Status	Notes
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists a bundled snapshot of Google's uptime-checker IP addresses with paging. They're reference metadata, not addresses of checkers that the emulator starts.

organizations.timeSeries

1 of 1 implemented · 1 known difference

Method	Status	Notes
list	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — checks for a numeric parent, a filter and an interval end, then reads an unpopulated, scope-specific store. It doesn't aggregate project time series or apply the interval and filter to project points. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — listing an organization's and a folder's time series with a custom `metric.type` filter and a one-hour interval answered HTTP 200 with an empty response.

folders.timeSeries

1 of 1 implemented · 1 known difference

Method	Status	Notes
list	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — checks for a numeric parent, a filter and an interval end, then reads an unpopulated, scope-specific store. It doesn't aggregate project time series or apply the interval and filter to project points. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — listing an organization's and a folder's time series with a custom `metric.type` filter and a one-hour interval answered HTTP 200 with an empty response.