## TL;DR
Intermittent bugs die in escalation because "sometimes it breaks" gives engineering nothing to work with. The template that gets action: how often it happens, what correlates with the failures, and what you already ruled out. Frequency plus correlation plus ruled-outs turns a shrug into a lead. Write it like a detective's case file, not a complaint.

## The query

```text
escalation template for intermittent bugs
```

## Use this when

- Engineering keeps bouncing escalations as "cannot reproduce"
- Flaky bugs sit in the queue for months with no owner
- Agents write escalations that read like customer complaints
- The same intermittent issue keeps coming back

## Not for

- Full outage or incident escalation
- Feature requests disguised as bugs
- Performance tuning and optimization asks
- Customer communication about the bug

## Steps

### 1. Quantify the frequency before anything else

"About 1 in 20 checkouts" or "three times this week across two accounts." A number tells engineering how hard to look and how to test the fix.

Expected output: every escalation opens with a frequency estimate.

### 2. List what correlates, honestly

Time of day, user action sequence, account type, device, anything that shows up more often in failures than in successes. Mark guesses as guesses.

Expected output: a correlation list with confidence levels, not certainties.

### 3. Document what you ruled out

"Not the browser cache, we had them clear it. Not account-specific, it hit three accounts." Ruled-outs save engineering from re-running your tests.

Expected output: a ruled-out section that gets longer as the investigation continues.

### 4. Attach the raw material

Timestamps of failures, ticket links, any logs or screenshots the customer provided. Raw beats summarized for intermittent issues.

Expected output: engineering can start investigating without asking for basics.

### 5. Name the customer impact of waiting

What happens if this takes another month: workarounds expiring, renewals at risk, support hours burned. Impact sets the priority.

Expected output: the escalation carries its own priority argument.

## Ready-to-use template

```text
INTERMITTENT BUG ESCALATION

What: [one-line description]
Frequency: [e.g. ~1 in 20, 3x this week]

CORRELATES WITH (confidence: high/medium/guess):
- [pattern 1]
- [pattern 2]

RULED OUT:
- [thing tested and cleared]
- [thing tested and cleared]

EVIDENCE: [ticket links], failures at [timestamps]

COST OF WAITING: [impact if this drags on]
OWNER: [agent name] | CUSTOMER: [account]
```

## Variant phrasings

### how to escalate flaky bugs to engineering

Frequency first, correlations with confidence levels, ruled-outs. That is the whole pitch.

### intermittent bug report template for support

Use the template above. The ruled-out section is what separates it from a complaint.

### getting engineering to fix cannot-reproduce bugs

Give them the frequency number and the raw timestamps. Repro starts from data, not from vibes.

## Why it happens

Support sees the bug through customer pain and writes about the pain; engineering needs the bug through reproduction and reads for the pattern. "Sometimes it breaks" contains zero pattern information, so it gets deprioritized behind everything with a clear repro. The template translates pain into the data shape engineering can act on.

## Edge cases

- Frequency is truly unknown: say so, and give the bounds ("at least twice, possibly more, customers underreport").
- Only one customer affected: say that up front. It changes the priority math honestly instead of hiding it.
- The bug stopped happening: keep the escalation open with a "watch" note and a date to close it if quiet.
- Engineering asks for more data you cant get: negotiate what is feasible instead of letting the ticket stall silently.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O3t6ZNoWNNLNyM8Y9_yQXg