Set up team-based alert routing

As alerts pile up, "everyone receives everything" quickly breaks down — people start ignoring alerts, and real signals get buried. With WhaTap's event reception tags, you can build "this alert goes only to this team" routing in 5 minutes.

This guide is for project administrators and alert operators in projects where team members have already been invited.

What you get from this guide

• Different alerts to different teams/roles
• Technical foundation for rotating incident responders (only the on-call gets the tag)
• Much lower noise compared to broadcasting to everyone

Prerequisites

• Team members already invited → Share a dashboard with your team
• At least one default event rule → Attach your first alert
• Member management permission (required to assign tags to other members)

Step 1. Create event reception tags

Path: Home > Project > Alert > Notifications

1. In the Event notification settings per-user section's user list, click the + Add tag (or +) button.
2. In the Event reception tag dialog, click the + Create new tag button.
3. Create tags by team or role:
   • Backend owner
   • DB team
   • Frontend owner
   • Admin
4. Pick a color and click the Create tag button.

Tag design principles

• Name tags by "who needs to see this alert" (role-based). Personal names force you to rename the tag every time someone changes roles or leaves.
• Start with 3–4 tags. Further subdivision can wait until you have signal.

Step 2. Assign tags to members

From the user list, assign the relevant tag to each team member.

1. Click the tag area next to a member's name and assign the new tag.
2. Multiple tags per member are allowed (for example, DB team + Admin).
3. When an event rule has a reception tag set, members without that tag do not receive the alert. If you still want everyone to receive the default alerts, leave them untagged.

Tags target recipients — they are not permissions

A tag alone does not grant the ability to receive alerts. The member must also have the Alert reception permission (and their own reception channel enabled) to actually receive alerts.

Step 3. Link tags to events

Wire the tags into actual event rules so routing takes effect.

1. Select Alert > Event settings menu.
2. In an existing event rule or a new one, find the Event reception tag field.
3. Choose tags that should be notified when this event fires.
   • Example: "DB connection pool threshold exceeded" → DB team
   • Example: "Payment API error rate spike" → Backend owner
4. Click the Save button.

If no tag is set

When the event reception tag is empty, the alert goes to all members of the project (the default behavior).

Step 4. Extend to on-call rotation

Rotate the tag assignment to get weekly/monthly on-call rotation instantly.

• This week: assign Backend owner to A
• Next week: remove from A → assign to B

Because event rules stay fixed and only the tag assignment changes, operational overhead stays low. A simple row on a team calendar or wiki ("This week's on-call: B") is enough.

Verify

• The Event notification settings per-user section shows tags and per-member assignments
• When a test event fires, only members with the designated tag receive the alert
• Untagged members do not receive the event — noise drops compared to broadcasting

The team-based alert routing foundation is ready. Stack escalation or third-party integrations on top and you have a real on-call system.

Reference — WhaTap's Stateful alerting

Beyond reducing recipients via tags, WhaTap manages alerts in a stateful way, which drastically reduces noise.

Table | Alert delivery behavior comparison

Style	Behavior
Stateless (common in other tools)	Re-send alert every time the threshold is crossed
Stateful (WhaTap)	Send only the first alert when the event turns On, suppress duplicates while the state holds, and clear when the state returns to Off

Even when the threshold condition persists for a long time, only the first occurrence and state transitions trigger alerts. This structurally reduces the fatigue of receiving the same event over and over. No extra configuration needed; this is the default.

Separate alert channels by severity

Combined with stateful behavior, splitting channels by severity is also effective.

• Critical → SMS / mobile push / PagerDuty or Opsgenie (urgent response)
• Warning → Slack or Teams channel (team-wide)
• Info / reference → Webhook or Email (logging)

Combined with per-user reception settings (email/SMS/WhatsApp/mobile), you can route urgent alerts only to the on-call's phone while sharing context with the team.

Next steps

• Repeat unresolved alerts → configure escalation (for example, 0, 1H, 1D for Critical only)
• Slack / PagerDuty / Webhook integrations → combine with external tools
• Bulk alert suppression → use event duration and throttling in event settings
• Pick your own reception channels → email/SMS/WhatsApp/mobile per-user settings (see Member permissions)