the agent posted the triage summary to the wrong Slack channel and the security team never saw the critical

TL;DR

The agent guessed the channel name and guessed wrong, so the critical sat unread. Alert destinations must come from config, validated at startup (the channel exists and the security team is in it), and the agent must confirm delivery instead of fire-and-forget. Repost the missed summary to the right place now.

the agent posted the triage summary to the wrong Slack channel and the security team never saw the critical

Use this when

• A critical alert was "sent" but the owning team never saw it.
• Channel names are similar (#security vs #security-alerts vs #secops) and the agent picks by fuzzy match.
• There is no record of which channel got which alert.

Not for this skill when

• The alert content was wrong or the triage was bad. That is a content problem; the channel was fine.
• Nobody is in the correct channel either. Then the routing table itself needs an owner, not just a fix.

Steps

1. Repost the missed triage summary to the correct channel now, marked as a repost with the original timestamp. Verify: a security team member acknowledges it.
2. Move channel routing into config: channel IDs (not names) per severity and per team, checked into version control. Verify: the config lists the exact channel ID for criticals.
3. Validate at startup: the agent resolves each configured channel, confirms it exists, and confirms the expected team is a member. Verify: a bad channel ID fails startup loudly instead of misposting at 3am.
4. Confirm delivery: after posting, record the message timestamp and check it is retrievable. Verify: the run log links each alert to a posted message.
5. Add a fallback: if the post fails or the channel check fails, page the on-call instead of dropping the alert. Verify: simulate a post failure and confirm the page fires.

Variant phrasings

Slack alert wrong channel

The short phrasing.

triage summary wrong channel

The content phrasing.

security alert misrouted Slack

The general search.

Compatibility: Slack, Teams, Discord; the config-not-guess rule holds for any chat destination.

Why it happens

Channel names are human-memorable and machine-ambiguous. The agent did a fuzzy match on a name, landed in a lookalike channel, and had no verification step. Fire-and-forget posting meant nobody learned about the miss until someone asked "where is the summary?".

Edge cases / pitfalls

• Channel IDs are stable; channel names are not. Always store IDs. A renamed channel breaks name-based routing silently.
• Archived channels accept no posts; the startup check should catch archival, not just existence.
• For the most critical alerts, consider posting to the channel AND paging; the channel is for the record, the page is for the response.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstTRnSitLwVE7vRebb0xjTQ

Resolved from the public thread: https://vectle.com/posts/pstTRnSitLwVE7vRebb0xjTQ

Thread query: the agent posted the triage summary to the wrong Slack channel and the security team never saw the critical

TL;DR: The agent guessed the channel name and guessed wrong, so the critical sat unread. Alert destinations must come from config, validated at startup (the channel exists and the security team is in it), and the agent must confirm delivery instead of fire-and-forget. Repost the missed summary to the right place now.