Note on scope
This isn't a Java SDK bug—we don't use this SDK. Our integration sends raw HTTP POST requests from Prometheus Alertmanager (written in Go). I'm filing this here because this repository contains prior discussions about legacy Custom Integration/platform-level webhook behavior. Happy to move this to a more appropriate repository if needed.
Summary
A legacy Slack Custom Integration Incoming Webhook, which had been working correctly for approximately three months with a channel field matching its own bound channel, suddenly began rejecting every request with 404 channel_not_found on 2026-07-08 19:11 UTC, despite no changes on our side.
Two other independently created legacy webhooks in the same workspace failed within minutes of each other.
Reproduction (live production webhook, no SDK involved)
POST {"text":"test"} (no channel field) → 200 ok, message is delivered to the webhook's bound channel.POST {"channel":"#talos-cluster-dev1-alerts","text":"test"} (exact matching channel name) → 404 channel_not_found.POST {"channel":"C0ANXNCPMC6","text":"test"} (exact matching channel ID, per documentation) → 404 channel_not_found.
Contradicts current documentation
The documentation for legacy Incoming Webhooks states that the channel field "should be an ID, such as C8UJ12P4P":
https://docs.slack.dev/legacy/legacy-custom-integrations/legacy-custom-integrations-incoming-webhooks/
We verified that the supplied channel ID is the correct ID for the webhook's target channel, yet Slack still returns 404 channel_not_found.
Relevant context from #699
In #699, @seratch mentioned that legacy Custom Integration webhooks should support the channel override for public channels.
Our webhook is bound to a private channel.
Is this distinction now intentional, or has the platform behavior changed since that discussion in 2021?
What we ruled out
- No code or configuration changes around 2026-07-08 (verified through complete Git history).
- Webhooks are still enabled (verified in the workspace's Custom Integrations admin page).
- Target channels were not renamed, archived, or deleted.
- No channel membership changes coincided with the failure.
- Not a network or firewall issue—the webhook returns a valid Slack
404 channel_not_found response, not a timeout or connection failure.
- The same Alertmanager binary and configuration continued running unchanged before and after the issue.
Current status
As a workaround, we removed the channel field from the webhook payload. Since each webhook is already bound to its intended destination channel, alerts immediately resumed flowing successfully.
All three affected webhooks have been working again since 2026-07-14 without specifying channel.
We're filing this issue to determine whether this is now expected or permanent platform behavior, and whether the change specifically affects private channels.
Note on scope
This isn't a Java SDK bug—we don't use this SDK. Our integration sends raw HTTP POST requests from Prometheus Alertmanager (written in Go). I'm filing this here because this repository contains prior discussions about legacy Custom Integration/platform-level webhook behavior. Happy to move this to a more appropriate repository if needed.
Summary
A legacy Slack Custom Integration Incoming Webhook, which had been working correctly for approximately three months with a
channelfield matching its own bound channel, suddenly began rejecting every request with404 channel_not_foundon 2026-07-08 19:11 UTC, despite no changes on our side.Two other independently created legacy webhooks in the same workspace failed within minutes of each other.
Reproduction (live production webhook, no SDK involved)
POST {"text":"test"}(nochannelfield) →200 ok, message is delivered to the webhook's bound channel.POST {"channel":"#talos-cluster-dev1-alerts","text":"test"}(exact matching channel name) →404 channel_not_found.POST {"channel":"C0ANXNCPMC6","text":"test"}(exact matching channel ID, per documentation) →404 channel_not_found.Contradicts current documentation
The documentation for legacy Incoming Webhooks states that the
channelfield "should be an ID, such asC8UJ12P4P":https://docs.slack.dev/legacy/legacy-custom-integrations/legacy-custom-integrations-incoming-webhooks/
We verified that the supplied channel ID is the correct ID for the webhook's target channel, yet Slack still returns
404 channel_not_found.Relevant context from #699
In #699, @seratch mentioned that legacy Custom Integration webhooks should support the
channeloverride for public channels.Our webhook is bound to a private channel.
Is this distinction now intentional, or has the platform behavior changed since that discussion in 2021?
What we ruled out
404 channel_not_foundresponse, not a timeout or connection failure.Current status
As a workaround, we removed the
channelfield from the webhook payload. Since each webhook is already bound to its intended destination channel, alerts immediately resumed flowing successfully.All three affected webhooks have been working again since 2026-07-14 without specifying
channel.We're filing this issue to determine whether this is now expected or permanent platform behavior, and whether the change specifically affects private channels.