Stakeholder vs On-Call Notifications

Why customers and engineers don't need the same updates, and how Signalog separates the two channels without duplicating work.

Two audiences, one incident

During an outage, you have two very different conversations happening:

Engineering needs raw signal. Log lines, hypothesis updates, “trying X now,” “rolled back, observing.” Speed and detail matter; polish doesn’t.

Customers need calm, factual communication. What’s affected, what’s the impact, when will it be fixed. Engineering jargon hurts; speculation is dangerous.

Most incident tooling forces you to pick: either you spam customers with engineering chatter, or you spam engineers with marketing-flavored updates. Signalog separates the two channels at the data model level so you can speak to both audiences from one form.

How it works in Signalog

Every incident update has a notify_subscribers flag. When you post an update from the incident detail page, you choose:

  • Notify subscribers (toggled on). The update is fan-out to:
    • The public status page (visible to anyone)
    • Subscribed customer emails
    • Web push notifications for status page subscribers
  • Internal note (toggled off). The update only appears on the incident detail page for the responding team

The default depends on the incident state and severity. For a major incident in investigating, the default is internal. You usually want to dig before announcing publicly. For a status transition (investigating → identified), the default is to notify, since customers want to know you’ve found the cause.

The on-call channel is separate again

notify_subscribers is about customer communication. The on-call paging channel is a third channel governed by escalation policies, not by per-update flags. When an incident is created, on-call is paged through SMS, voice, Slack DM, or whatever channels their escalation policy specifies. Independent of whether subscribers are notified.

So a typical incident has three audiences, three channels:

ChannelWhoWhenHow
On-call pagingResponding engineer(s)Incident creation + escalation stepsSMS / voice / Slack DM / email
Internal updatesResponding teamEvery update with notify_subscribers=falseIncident detail page + audit log
Stakeholder updatesCustomers, exec, supportEvery update with notify_subscribers=trueStatus page + subscriber email + web push

Templates for each audience

Communication templates can be tagged by audience:

  • On-call templates: for paging messages (rare, since most pages are auto-generated)
  • Stakeholder templates: pre-written customer-facing updates with {{variables}} for service names, components, and timestamps

A typical stakeholder template:

We’re investigating elevated error rates affecting {{component}}. Our team is actively working on this and will provide an update within 30 minutes. We apologize for the inconvenience.

When you post a stakeholder update, pick the template, fill in the variables, hit notify. The polished version goes to customers; the raw timeline stays internal.

Major incidents promote selectively

When you declare a major incident, the incident gets a “major” badge but updates still flow through the same notify_subscribers toggle. Major status doesn’t auto-promote internal notes to subscribers. It only changes the response model (war room, roles, conference bridge).

This is intentional: even during a P1, you don’t want every “trying foo” comment broadcast to customers. The Comms Lead role exists specifically to curate what subscribers see.

What this looks like in practice

A typical incident timeline:

14:32  [PAGE]      API gateway 5xx → on-call paged via SMS
14:33  [INTERNAL]  "Auth service throwing 503s, looking at deploy 3a4f"
14:35  [STAKEHOLDER] "We're investigating elevated error rates on the API"
                     → email + status page + web push
14:38  [INTERNAL]  "Rolled back 3a4f, watching"
14:41  [INTERNAL]  "Recovery confirmed"
14:42  [STAKEHOLDER] "Resolved — issue was a deploy regression, rolled back"
                     → email + status page + web push
14:42  [RESOLVE]   Incident resolved, postmortem queued

Five updates in 10 minutes. Only two reached customers. Engineers had the full timeline; customers had a calm two-message arc.

Why this matters

Mixing the two channels is the most common reason status pages become noise. Customers stop subscribing because they get spammed with engineer-speak; engineers stop posting raw updates because they don’t want to scare customers. Both audiences end up worse off.

Separating the channels means your raw timeline can be as raw as it needs to be. And your customer communication can be as polished as it needs to be. Without either side getting in the other’s way.

Next steps