Last updated Nov 2, 2026.
Point a Cloud Monitoring webhook notification channel at OpsPing and each alerting-policy incident pages on-call: an open incident creates one alert, repeat notifications deduplicate into it, and the closed notification closes it. No transformation layer is needed; OpsPing reads Cloud Monitoring's native webhook JSON.
Setup
- In OpsPing, open Integrations, add a Google Cloud Monitoring integration, pick a default service, and copy its webhook URL. Treat the URL as a secret: the token in it is the credential.
- In the Google Cloud console, go to Monitoring → Alerting → Edit notification channels, and in the Webhook section click Add new (Google's instructions ↗).
- Paste the OpsPing URL as the endpoint, give the channel a display name, and save. No basic auth is needed.
- Add the webhook channel to the Notifications section of each alerting policy that should page, and keep notifications on incident close enabled so recoveries close the alert.
- Trigger a real policy (for example, a low threshold on a test resource) and confirm the alert opens and closes. Test Connection on the channel sends Google's sample payload; if it creates an alert in OpsPing, close it by hand.
Field mapping
| Cloud Monitoring field | OpsPing alert |
|---|---|
incident.incident_id | Alias gcp:<incident id>; stable for the incident's lifetime |
incident.state | open creates (or dedupes); closed closes the matching alert |
incident.summary | Message (falls back to policy_name; truncated to 130 characters) |
incident.severity | Priority: critical P1, error P2, warning P3, info P4, no severity P3; also tagged severity:<value> |
incident.documentation.content | Description (your policy's documentation, so runbook text reaches the responder) |
incident.resource.labels.instance_id | Entity (falls back to resource_name) |
policy_name, condition_name, url, observed_value, resource labels | Details, including the link to the incident in the Google Cloud console |
Every alert is also tagged provider:gcp, which you can match in alert policies. Setup screenshots are in the NOC automation docs.
Notes
- Cloud Monitoring webhooks only reach public endpoints;
api.opsping.comis public, so no Pub/Sub relay is needed. - Use one OpsPing integration per project or per service if you want alerts to land on different default services.
FAQ
Does OpsPing need a Pub/Sub topic or Cloud Function for Cloud Monitoring?
No. OpsPing reads Cloud Monitoring's native webhook payload directly, so a webhook notification channel pointed at the integration URL is enough.
Do closed Cloud Monitoring incidents close the OpsPing alert?
Yes. The closed notification carries the same incident_id, and OpsPing closes the alert with alias gcp:<incident id>, even if it was already acknowledged.
How is priority set?
From the alerting policy's severity: critical is P1, error P2, warning P3 and info P4. Policies without a severity become P3, so set a severity on each policy you route to OpsPing.