Why isn't my Slack notification channel delivering anything even though it shows as created?

Most likely it's unverified. Channels other than webhook and Pub/Sub types generally require completing a verification step, for Slack this means the OAuth app-install flow, before Monitoring will actually deliver to them. A channel created purely via API can sit in a created-but-unverified limbo indefinitely if no one completes that step in the console.

Can I use a legacy Slack incoming webhook URL instead of the OAuth integration?

No, Cloud Monitoring's Slack notification channel type uses the Google Cloud Slack app's OAuth-based integration, authenticated per-workspace, not a raw incoming webhook URL. If you have an old webhook-based Slack setup from a different tool, it won't slot into this channel type directly, you need to install and authorize the Monitoring Slack app in your workspace.

Does deleting a notification channel remove it from alerting policies that reference it?

The alerting policy retains the (now-dangling) channel reference, it doesn't automatically clean itself up. A policy that references a deleted channel will simply stop notifying through that path without an obvious error, so audit and update policies before deleting a channel they depend on, not after.

GCP Notification Channel Builder

MonitoringGCP

Build Monitoring notification channel configurations for email, Slack, PagerDuty, and webhooks.

Monitoring Notification Channels Configuration

Build Monitoring notification channel configurations for email, Slack, PagerDuty, webhooks, and Pub/Sub integrations.

Required Fields

channels

{
  "channels": [
    {
      "type": "email",
      "displayName": "SRE On-Call Email",
      "description": "Primary email for critical alerts",
      "labels": {
        "email_address": "sre-oncall@example.com"
      },
      "enabled": true,
      "userLabels": {
        "severity": "critical",
        "team": "sre"
      }
    },
    {
      "type": "slack",
      "displayName": "SRE Slack Channel",
      "description": "Slack notifications for platform alerts",
      "labels": {
        "channel_name": "#sre-alerts",
        "auth_token": "<REDACTED>"
      },
      "enabled": true,
      "userLabels": {
        "severity": "warning",
        "team": "sre"
      }
    },
    {
      "type": "pagerduty",
      "displayName": "PagerDuty Critical",
      "description": "PagerDuty integration for P1 incidents",
      "labels": {
        "service_key": "<REDACTED>"
      },
      "enabled": true,
      "userLabels": {
        "severity": "critical"
      }
    },
    {
      "type": "webhook_tokenauth",
      "displayName": "Custom Webhook",
      "description": "Custom webhook for incident management system",
      "labels": {
        "url": "https://incidents.example.com/api/alerts",
        "password": "<REDACTED>"
      },
      "enabled": true,
      "userLabels": {
        "integration": "custom"
      }
    },
    {
      "type": "pubsub",
      "displayName": "Alert Pub/Sub Topic",
      "description": "Pub/Sub topic for programmatic alert handling",
      "labels": {
        "topic": "projects/my-project/topics/monitoring-alerts"
      },
      "enabled": true,
      "userLabels": {
        "integration": "pubsub"
      }
    }
  ]
}

Generated Output

Output will appear here...

About This Tool

Build Cloud Monitoring notification channel configurations across email, Slack, PagerDuty, custom webhooks, and Pub/Sub. Most channel types other than webhook and Pub/Sub require a verification step (a confirmation email click, or an OAuth-based Slack app install) before Monitoring will actually deliver to them, a channel created via API in an unverified state silently accepts alert routing configuration pointed at it but never delivers anything until someone completes verification in the console. The Slack integration specifically needs a modern OAuth token from the Google Cloud Slack app, not a legacy incoming webhook URL, which is a common point of confusion for teams copying an old Slack integration pattern from another tool.

Real-World Scenario

A team sets up a new PagerDuty and Slack notification channel pair for a critical alerting policy ahead of a product launch, tests the policy by manually triggering a test alert, and the Slack message never arrives even though PagerDuty fires correctly. Checking the Monitoring console shows the Slack channel sitting in an unverified state, because the channel was created via a Terraform apply with no one following up to complete the OAuth install step it requires. They use the builder to confirm the channel JSON itself is correctly formed, then complete the missing verification step in the console, after which the same alerting policy delivers to Slack on the next test fire.

When to Use This Tool

•Debugging why an alerting policy shows as firing but a configured Slack channel never receives a message, tracing it back to the channel sitting in an unverified state since no one completed the OAuth flow after creating it via API.
•Adding a pagerduty channel with the integration's service_key so P1 alerting policies escalate directly into the on-call rotation instead of relying on someone watching an email inbox.
•Setting up a pubsub channel type so alert firing/resolution events can be consumed programmatically by an internal incident-management system, instead of only supporting human-facing notification types.
•Scoping userLabels by severity and team across a set of channels so alerting policies can be composed consistently (critical alerts fan out to PagerDuty + Slack, warnings go to Slack only) without hardcoding channel IDs in every policy.

Pro Tips

TIP

webhook_tokenauth and pubsub channel types skip the human verification step entirely since there's no human inbox or app-install involved, making them the more reliable choice for anything you need working immediately after programmatic creation.

TIP

PagerDuty's service_key is the integration key for a specific PagerDuty service, not an account-wide API key, using the wrong kind of key is a common setup mistake that produces a channel that accepts creation but never actually triggers an incident.

TIP

A channel's enabled: false flag is easy to miss during a config review since the channel otherwise looks fully configured, it silently no-ops instead of erroring, verify enabled status specifically when debugging a 'this channel isn't working' report.

How It Works Under the Hood

The builder requires channels to resolve as present, and treats each array entry as a NotificationChannel resource matching Monitoring's schema (type, displayName, labels, enabled); it validates the JSON shape but can't confirm a channel is actually verified or that credentials like service_key or auth_token are valid, that only happens against the live API.

Frequently Asked Questions

Why isn't my Slack notification channel delivering anything even though it shows as created?: Most likely it's unverified. Channels other than webhook and Pub/Sub types generally require completing a verification step, for Slack this means the OAuth app-install flow, before Monitoring will actually deliver to them. A channel created purely via API can sit in a created-but-unverified limbo indefinitely if no one completes that step in the console.
Can I use a legacy Slack incoming webhook URL instead of the OAuth integration?: No, Cloud Monitoring's Slack notification channel type uses the Google Cloud Slack app's OAuth-based integration, authenticated per-workspace, not a raw incoming webhook URL. If you have an old webhook-based Slack setup from a different tool, it won't slot into this channel type directly, you need to install and authorize the Monitoring Slack app in your workspace.
Does deleting a notification channel remove it from alerting policies that reference it?: The alerting policy retains the (now-dangling) channel reference, it doesn't automatically clean itself up. A policy that references a deleted channel will simply stop notifying through that path without an obvious error, so audit and update policies before deleting a channel they depend on, not after.

Related Learning Guides

Firestore Data Modeling26 min read
Cost Optimization Guide24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.