Skip to main content
Personalized Service Health writes the Google Cloud events that affect your projects (event creations and updates) to Cloud Logging and integrates with Cloud Monitoring log-based alerting policies. A log-based alerting policy can send its notifications through a webhook notification channel. The Flashduty Google Cloud Monitoring integration accepts this webhook, so no separate Personalized Service Health integration is needed: create a Google Cloud Monitoring integration in Flashduty, paste its push URL into a webhook notification channel, and use the channel in a Service Health alerting policy.

​
In Flashduty On-call

Get an integration push URL in either of the two ways below. Choose the Google Cloud Monitoring integration type in both, not Personalized Service Health.

​
Use a dedicated integration

  1. In the Flashduty console, go to Channels and open a channel
  2. Go to Settings → Integrations → Dedicated integrations and click Add an integration
  3. Select Google Cloud Monitoring and click Save
  4. Open the generated integration card and copy the Push URL, in the form https://api.flashcat.cloud/event/push/alert/google-cm?integration_key=<integration key>

​
Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Google Cloud Monitoring and enter an integration name
  3. Configure the default route and select a channel; you can add more rules under Routes after creation
  4. Click Save and copy the generated Push URL

​
Configure in Google Cloud

​
Step 1: Prepare

  1. Enable the Service Health API in the project you want to receive events for, and make sure billing is enabled for it
  2. The account that configures alerts needs these IAM roles on the project: Logs Configuration Writer (roles/logging.configWriter), Monitoring AlertPolicy Editor (roles/monitoring.alertPolicyEditor), Monitoring NotificationChannel Viewer (roles/monitoring.notificationChannelViewer) and Personalized Service Health Viewer (roles/servicehealth.viewer)

​
Step 2: Create a webhook notification channel

  1. In the Google Cloud console, go to Monitoring → Alerting and click Edit notification channels
  2. In the Webhook section, click Add New, enter the push URL copied above as the Endpoint URL, and enter Flashduty as the Display Name
  3. Click Test Connection, then click Save
Per Google, webhooks only support public endpoints, which the Flashduty push URL is.

​
Step 3: Create a Service Health alerting policy

Use either method. Method 1: In the Service Health dashboard
  1. Open the Service Health dashboard and click Create Alert Policy at the upper right
  2. Choose an alerting policy template, select the webhook channel from Step 2 as the notification channel, and click Create Policies
  3. To change the condition, choose Customize alert policy in the template’s menu
Method 2: With gcloud
Example policy.json. NOTIFICATION_CHANNEL is the resource name of the channel from Step 2, in the form projects/PROJECT_ID/notificationChannels/885798905074 (list them with gcloud beta monitoring channels list):
filter is the log filter. Common conditions from the Google documentation: Product IDs and location names are listed in the Google documentation Google Cloud products and locations. Set the Policy severity level (API field severity) in the alerting policy; Flashduty uses it for the alert severity.

​
Step 4: Test

Following the Google documentation, write a test log entry to Cloud Logging, wait a few minutes, and confirm the alert in Monitoring → Incidents and in Flashduty. Wait at least 5 minutes before testing again.
Use the Service Health log name for LOG_NAME; the Google documentation uses the format projects/PROJECT_ID/logs/servicehealth.googleapis.com%2Factivity.

​
Enable the auto-resolve timeout

For log-based alerting policies, Cloud Monitoring only sends a notification when an incident opens, not when it closes (the API documents the notification prompt of log-based policies as always OPENED), so Flashduty receives no recovery notification. Enable the auto-resolve timeout on the channel that receives these alerts, choose Incident trigger as the window timing start, and start with 24 hours, adjusted to the usual duration of the events you care about. The autoClose setting in the alerting policy only decides when the incident closes in Cloud Monitoring (7 days by default for log-based alerts); it does not notify Flashduty.

​
Field mapping

​
Troubleshooting

  • No alert arrives: confirm in Monitoring → Incidents that the incident opened; check whether the log filter matches, and note that notifications are rate limited (the Google documentation gives 20 alerts per policy per day per project as an example)
  • The alert does not recover: log-based alerts send no closure notification, so enable the channel’s auto-resolve timeout
  • Test Connection fails: confirm the Endpoint URL is the full push URL, including integration_key
  • Several updates of one event produce several alerts: each Cloud Monitoring incident (incident_id) maps to one Flashduty alert; using the new_event condition notifies only for new events and reduces the number of alerts
For more details, see the Google documentation Configure alerts through Cloud Logging, Example alerting policies and conditions and Create and manage notification channels.