I assumed adding a new alert channel meant "format a message, POST it to a webhook." Seven providers later, I can tell you that's true for maybe one of them. Every other one has an opinion — a character limit, a deprecated field, a soft-deprecated payload shape — and it will not tell you kindly.
Impulseye sends alerts through nine channels now: Discord, Slack, Teams, Telegram, Google Chat, PagerDuty, Pushover, email, and generic webhooks. This is the list of things that actually broke, or almost did, while building that out.
Character limits
The first surprise wasn't a bug — it was realizing that "send a message" is really "send a message that fits inside a hard, service-specific limit, silently truncated or flatly rejected if you don't check first."
Slack — a header block caps at 150 characters. A long monitor name plus status text blows past this more often than you'd think.
Discord — an embed field value caps at 1024 characters, and the entire payload caps at 6000. Field-level truncation isn't enough; you have to budget the whole message.
Pushover — title caps at 250, message at 1024, and the url field (used for linking back to the monitor) caps at 512.
None of these limits are documented in the same place, in the same units, or with the same failure behavior. Some truncate. Some reject the whole request. The only way to be sure is to build every payload against every limit and check before you ship — which is the origin story of a regression harness I'll get to at the end.
Silent deprecations
Telegram's Bot API used to accept disable_web_page_preview directly on a message. It still does, technically — but the field is soft-deprecated in favor of a nested link_preview_options object, and nothing about the old field errors or warns you. It just quietly stops being the recommended way, and newer client behavior increasingly assumes the new shape.
// Old (still "works", quietly discouraged)
{ "disable_web_page_preview": true }
// Current
{ "link_preview_options": { "is_disabled": true } }Subscribe to the provider's API changelog, not just their docs page. Docs describe the current state; changelogs tell you something is changing before your integration quietly becomes the old way of doing things.
Teams caveat
Microsoft retired the old Office 365 Connector webhook format. If you're integrating Teams today, you want Workflows — a different setup path entirely, with a different payload shape. Anything you find that references the old Connector URL format is already writing about a deprecated feature, even if it was published recently.
What changed
- I no longer trust a provider's docs page to be the whole story — the changelog and any "migration guide" pages matter as much as the API reference.
- Every new channel gets its message builder run against every alert type and every field-length edge case before it's considered done, not after a user reports a truncated alert.
- I assume every provider has a regional or versioned quirk until proven otherwise, rather than the other way around.
None of these are hard problems individually. What made them costly is that they're all invisible until triggered — a long monitor name, a client that finally drops the old preview field, a channel with a limit nobody thought to check. The only real defense turned out to be testing the full combinatorial space up front instead of waiting for reality to find the gaps for me.