Skip to main content
The Hard Parts.dev
RF-50 Process · Operational RF Red Flags
Severity high Freq common

Incidents bounce without resolution

An incident moves between teams, channels, or owners because no one has clear authority over the failing end-to-end behavior.

Severity
high
Frequency
common
First noticed by
incident commander · support lead · on-call engineer
Detectability
obvious
Confidence
high
At a glanceRF-50
Where you see this

distributed servicesshared platformsthird-party integrationscross-team customer workflows

Not necessarily a problem when
a brief routing step is part of a clear incident triage model
Often mistaken for
we need more experts in the room
Time horizon
immediate
Best placed to act

incident commanderservice ownerengineering manager

The signal

What you would actually notice

Bouncing incidents waste recovery time and reveal that ownership boundaries do not match runtime behavior.

Field observation

Teams keep redirecting the incident to another owner, another service, or another queue while customer impact continues.

Also observed

  • Our service is green, check with platform.
  • Platform says the product team owns the workflow.
  • No one is sure who can declare this resolved.

Primary reading

What it usually indicates

Most likely underlying patterns when this signal shows up. Not a diagnosis, a starting hypothesis.

Usually indicates

Most likely underlying patterns when this signal shows up.

  • ownership drift
  • service ownership gap
  • dependency fog
  • unclear operational contracts

Stakes

Why it matters

Bouncing incidents waste recovery time and reveal that ownership boundaries do not match runtime behavior.

Inspection

What to check next

Deliberate steps to confirm or disconfirm the primary reading above. Not a checklist. An order of inspection.

  1. incident timeline
  2. service ownership map
  3. runbook handoff rules
  4. dependency contracts
  5. customer impact owner

Diagnostic questions

Questions to ask the team, or yourself, before concluding anything.

  1. Who owns customer impact right now?
  2. Which service or workflow owner can coordinate the response?
  3. What evidence is required before handing off?
  4. Which boundary failed operationally?

Progression

Under the signal

Where this pattern tends to come from, what's holding it up, and where it goes if nothing changes.

Leading indicators

What tends to show up first.

  • incident channels include many observers and few decision owners
  • teams argue about whether the issue is upstream or downstream
  • handoffs lack a clear next action

Common root causes

What is usually sitting under the signal.

  • service ownership ends at the API
  • shared dependencies lack operational owner
  • runbooks describe components, not workflows
  • teams optimize local availability

Likely consequences

What happens if nothing changes.

  • longer time to recovery
  • customer-visible confusion
  • post-incident blame
  • new governance added without ownership repair

Look-alikes

Not what it looks like

Patterns that can be mistaken for this signal, and 'fix' attempts that make it worse.

False friends Things the signal is often confused with, but isn't.
  • we need more experts in the room
  • it is probably another team's service
  • our dashboard is green

Anti-patterns when responding

Responses that feel sensible and usually make the underlying pattern worse.

  • opening more incident channels instead of naming an owner
  • waiting for the perfect technical diagnosis before assigning customer-impact ownership
  • calling the incident resolved when only local symptoms are cleared

Context

Context and ownership

Where this signal surfaces, who sees it first, who can actually act, and how much runway there usually is before escalation.

Common contexts

Where it shows up

  • distributed services
  • shared platforms
  • third-party integrations
  • cross-team customer workflows
Most likely to notice

Who sees it first

Before it escalates.

  • incident commander
  • support lead
  • on-call engineer
Best placed to act

Who can move on it

Not always the same as who notices it.

  • incident commander
  • service owner
  • engineering manager
Time horizon

immediate

How much runway there usually is before the signal hardens into the underlying pattern.

AI impact

AI effects on this signal

How AI-assisted and AI-driven workflows tend to amplify or hide this signal.

AI amplifies

Ways AI tooling tends to make this signal louder or more common.

  • AI can summarize each team's local evidence while missing the unowned workflow failure.

AI masks

Ways AI tooling tends to hide this signal, so it keeps growing under the surface.

  • AI incident summaries can make a bounced response look like broad collaboration.

Relationships

Connected signals

Related failure modes, decisions behind the signal, response playbooks, and neighboring red flags.