Patterns at scale

min

Once you're past three integrations and one team, the configuration choices that didn't matter on day one start to matter a lot. This page is the playbook teams running Intello at scale settled on.

Pattern 1 — One Slack channel per consuming team, not per vendor

Don't create #stripe-changes, #openai-changes, #twilio-changes. Create #billing-team-alerts, #ai-team-alerts, #platform-alerts.

Vendor-per-channel sounds organized but breaks the moment one vendor (Stripe) is consumed by three teams. Team-per-channel scales linearly with your org and stays useful when you add new vendors.

Use domain mappings to do the routing — map "billing area of Stripe" → #billing-team-alerts.

Pattern 2 — On-call rotates the handle, not the integration

Most platforms have a rotating on-call engineer. Don't reassign domain mappings every week to track the rotation. Instead:

Map services to a static "on-call" handle (@oncall-platform in Slack, a PagerDuty service).
Let your on-call tool resolve who that is right now.

Intello pings the handle. Slack and PagerDuty figure out the human. You never touch Intello when on-call rotates.

Pattern 3 — Quarterly review of severity defaults

Your defaults will drift from reality. Once a quarter, sit down with your data and ask:

Which severity tiers got triaged inside the SLA you wanted?
Which got ignored?
Which should have paged but didn't?

Adjust org-level severity rules once per quarter. Resist the urge to tune in real time after one bad alert — small samples produce bad rules.

Pattern 4 — Treat new integrations like new tests

A new integration is opt-in noise until someone owns triage for it. Adopt this rule: every new integration must have a domain mapping and an owner before it enters production routing. Until then, it routes to a #integrations-staging channel where someone is responsible for shaking it out.

This single rule kills 80% of "what is this alert and who cares?" conversations.

Pattern 5 — Use severity windows during release weeks

If your team has a release calendar, you can suppress non-breaking alerts during release windows so on-call isn't drowned in noise during deploys. Settings → Alert preferences → Quiet hours supports recurring schedules.

Breaking changes always get through. There is no setting to silence them. Don't ask.