Skip to main content

Team collaboration scenario

One person using WhaTap well and a team running it as an operational system are different stories. This guide bundles the collaboration patterns needed at the team level — dashboards, alerts, permissions, handover, and rituals.

Who this guide is for
  • Leads expanding personal usage into team-wide usage after adoption
  • Teams starting or already running on-call rotation
  • Engineering managers and MSPs overseeing multiple teams or projects

Prerequisites​

Five axes of collaboration​

  1. Shared observability assets (dashboard, Flexboard)
  2. Alert distribution (routing by role/owner)
  3. Permission model (who can do what)
  4. Handover (prevent loss at role transitions)
  5. Regular rituals (when does the team open WhaTap?)

① Run shared observability assets​

Team shared Flexboard​

  • Maintain the one page the team opens every day. Pin the Flexboard URL in Slack channel bookmarks / collaboration tools
  • Widget composition should only reflect metrics the team actually uses in daily decisions. More visible ≠ better dashboard
  • Announce composition changes in the team channel — members should know why the screen changed

Multi-product integration​

When mixing multiple products → Combining product metrics with Flexboard

② Alert distribution — role/owner based​

  1. Design role tags: incident owner, DB team, admin, etc. — role-centric
  2. Move on-call tags in rotation: A this week, B next week
  3. For each event rule, specify which tag receives it
  4. Reduce noise:
    • Warning → channel message; Critical → SMS/mobile
    • Throttling / escalation (0, 1H, 1D) for repeats of the same event

Details: Configure anomaly reception

Team collaboration tool integration​

  • Slack Webhook — separate by channel (e.g., #alert-backend, #alert-db)
  • Third-party integrations — combine with external ops tools like PagerDuty or Opsgenie (check paid features)

③ Permission model — "who can do what"​

WhaTap doesn't use fixed roles — it uses per-feature permission checkboxes. Adjust permission operations by team size.

Small team (≤ 5)​

  • Grant Edit + Alert reception to most members
  • 1–2 members with Member management
  • 1 team lead with BILLING

Mid-size team (6–20)​

  • Default view access for everyone
  • Alert reception + Alert settings only for those eligible as incident responders
  • Edit + Flexboard editor for infra/dashboard owners
  • 2–3 members with Member management (including backup)

Large organization (multiple teams, multiple projects)​

Use the organization-group-project 3-tier structure:

Permissions granted at the upper level (organization) cascade down (project). Keep organization/group management only with team leads; each team runs its details autonomously.

Full permission list: Member permissions

④ Handover — prevent loss at role transitions​

On-call rotation is the knowledge transfer chokepoint. Looking at a few WhaTap screens together during handover changes the next responder's response speed.

Handover checklist (within 15 minutes)​

  1. Events during the previous shift — share via Event history with a time filter
  2. Currently-watching issues — URL + one-line description (if any)
  3. Attention points today/this week — planned deploys, traffic events, etc.
  4. Move the owner tag — reassign the responder tag in per-user event reception
Handover template

Pin the following template in the team wiki and update at each shift.

## Handover — YYYY-MM-DD → YYYY-MM-DD
- Next owner: @name
- Key events: (none / details: ...)
- Watching: (none / link + one line)
- Attention: (deploys, events, maintenance, etc.)
- Owner tag moved: ✓

⑤ Team rituals — fix when WhaTap is opened​

Technology sticks only when it's inside the ritual.

Daily standup (1 min)​

  • Scan the shared Flexboard — any anomalies yesterday, anything to watch today?

Weekly team meeting (5 min)​

Pre/post deploy (10 min)​

Post-incident retro (within 1–3 days)​

Quarterly retro (90 min)​

  • Analyze incident patterns in the quarter → revisit event rules, dashboards, permission structure

Change history tracking — find setting issues quickly​

When multiple people modify settings, "when did things break?" gets hard to trace. WhaTap auto-records project setting changes in the User behavior menu.

  • Issue after a setting change → shorten root cause by checking user behavior
  • Details: User behavior

Verify​

  • The shared Flexboard URL that team members open daily is bookmarked in the team channel
  • Each event rule has a receiving tag assigned — no "broadcast to everyone"
  • Team members follow a 15-minute handover checklist at rotation
  • Opening WhaTap screens is ritualized into weekly meetings, deploy times, and retros
  • Large orgs have permission delegation set up via organization-group-project tiers

Once team collaboration is in place, WhaTap becomes the team's shared cognitive system, not a personal tool. Knowledge is stored in team operational structure, not one person, so quality holds even when owners rotate.

Next steps​

Last updated on