We are attempting to automate incident notifications by triggering a Slack message whenever a specific queue breaches its service level agreement. The infrastructure is defined using the CX-as-Code Terraform provider, but the runtime behavior is unexpected.
The Terraform configuration defines the webhook with the genesyscloud_routing_queue resource and a genesyscloud_routing_webhook resource. The webhook is configured to trigger on QUEUE_STATISTICS events. The payload is constructed using a JSON template within the Terraform resource definition.
Here is the relevant snippet from the Terraform module:
resource "genesyscloud_routing_webhook" "sla_breach_webhook" {
name = "SLA Breach Notification"
description = "Sends Slack alert on SLA breach"
status = "ENABLED"
endpoint = "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"
method = "POST"
content_type = "application/json"
header {
name = "Authorization"
value = "Bearer ${var.slack_bot_token}"
}
payload = jsonencode({
"blocks" = [
{
"type" = "section",
"text" = {
"type" = "mrkdwn",
"text" = "*SLA Breach:* Queue *${local.queue_name}* has exceeded target wait time."
}
}
]
})
trigger {
event = "QUEUE_STATISTICS"
filter = "slaPercent < 80"
}
}
The symptom is that the webhook appears to fire correctly in the Genesys Cloud admin console logs. The status shows “Sent” initially, but then updates to “Failed” with an HTTP 500 Internal Server Error returned from the endpoint. However, when we manually test the same JSON payload against the same Slack webhook URL using Postman, it succeeds with a 200 OK.
We suspect the issue might be related to how Genesys Cloud serializes the event payload or handles the header injection. The Slack API documentation states that incoming webhooks do not require an Authorization header, yet removing it does not resolve the 500 error. The 500 error from Slack usually indicates a malformed payload or an unsupported feature in the block kit structure.
The event payload structure from Genesys Cloud includes nested objects for queueMetrics and slaMetrics. We are using the default payload transformation which sends the entire event envelope. Perhaps the size of the envelope is causing the issue? Or maybe the filter expression slaPercent < 80 is not evaluating correctly, causing the webhook to send partial or malformed data?
Has anyone successfully implemented a similar SLA breach webhook using Terraform? We have verified that the Slack channel exists and the webhook URL is valid. The Terraform apply completes without errors, and the resource is created in the Genesys Cloud UI. The failure occurs only at runtime when the event triggers.
We are using the latest version of the genesyscloud Terraform provider. The environment is Genesys Cloud EU. The timezone for the queue is Europe/Berlin, which might affect the SLA calculation window, but the webhook should still fire if the metric is breached.
The error log in Genesys Cloud shows:
HTTP 500: Internal Server Error. Response body: {"ok": false, "error": "invalid_blocks"}
This suggests the JSON blocks are invalid. Yet the static JSON in the Terraform file is valid. We are wondering if Genesys Cloud is injecting additional fields into the payload that break the Slack block structure. For instance, if the text field receives a null value or an unexpected data type from the event context, it might cause Slack to reject the message.
We have tried hardcoding the text in the payload, as shown in the snippet. The error persists. We are unsure if the filter condition is causing the event payload to be truncated or modified in a way that conflicts with the static payload template. The documentation for genesyscloud_routing_webhook is sparse regarding payload merging behavior.
We need to determine if the issue lies in the Terraform configuration, the Genesys Cloud webhook engine, or the Slack API interpretation of the incoming data. We are open to suggestions on how to debug the exact payload being sent. We cannot easily log the outbound request from the Genesys Cloud side. The webhook logs only show the status and timestamp, not the request body.