Emerging

Quiet failure surfacing

A background failure becomes a visible, actionable state rather than an absence of output.

MChurn-risk reportWeekly · Mon 28 Sep, 08:00 Incomplete

Billing data didn't load, so this report is missing accounts

Billing connector: access token expired at 03:12. Payment and renewal signals are missing for 64 accounts.

2 of 3 automatic retries used · next at 09:00

Accounts at risk1 found · partial

KC Kite & Co 12 seats
Usage down 46% in 30 days · 3 open tickets Medium

Checked with 2 of 3 sources. Accounts flagged only by billing signals can't appear until billing loads.

Sources

Support tickets
1,204 tickets · synced 07:58
Product usage
88 accounts · synced 07:59
Billing
Failed at 03:12 · last good sync Sat 26 Sep

Try it: The billing source failed overnight. Retry it (and hit the retry limit), or reconnect it and see the accounts the broken sync was hiding.

In the wild

How 2 products ship this pattern. Click a screenshot to enlarge it.

Copilot Studio activity map showing an 'Add a to-do (V3)' connector step with its To-do List input flagged in red as 'Missing required information', and a red 'Session incomplete' badge below the step. — Microsoft Copilot Studio
When an event-triggered agent run stalls, the activity map flags the exact connector input that failed and marks the run 'Session incomplete' instead of showing nothing.
Source: Microsoft Learn ↗

Hightouch sync Runs tab listing runs with amber 'Completed with errors' statuses, one red 'Failed after 1m' run with a 'See error message' link, red rejected-row counts, and a View run button per row. — Hightouch
Every background sync run gets an explicit status, so failed and partly failed runs show red counts and an error link instead of passing for an empty sync.
Source: Hightouch docs ↗

When to use

Any invisible pipeline the user would otherwise assume had succeeded.

Seen in

Connector sync error banners, agent run failure cards, enrichment retry prompts.

For engineers

Distinguish empty-result from error at the API level; retries need a user-visible ceiling.

Build prompt

A neutral, component-only prompt for a coding agent. Edit the stack block or anything else to fit your project, then copy it.

# Build the "Quiet failure surfacing" pattern: `PipelineFailureNotice`

## Stack (edit this block to match your project)
- React 18+ with TypeScript: one function component, typed props, no `any`.
- Tailwind CSS, using your design system's tokens if you have them.
- Presentational only: data comes in through props, decisions go out through callbacks. No fetching or global state inside.
- If your codebase already has conventions (naming, shared components, tokens), follow them over this spec.

## What the pattern is for
A background failure becomes a visible, actionable state rather than an absence of output.

Use it when: Any invisible pipeline the user would otherwise assume had succeeded.

## What to build
A visible failure state for a background pipeline (sync, enrichment, scheduled job) that would otherwise just produce nothing. It says what failed, what is missing because of it, and what the person can do, with a capped retry. It renders in place of, or above, the results the pipeline feeds.

### Props
- `source`: { name: string; lastSuccessAt?: Date }, the pipeline or connector, e.g. "Billing sync".
- `status`: "ok" | "empty" | "failed" | "retrying" | "retry-exhausted" | "recovering", controlled; `empty` and `failed` are distinct values from the API, never inferred from a zero count.
- `error?`: { message: string; cause: "transient" | "auth" | "config" | "unknown"; at: Date }, the plain-language reason.
- `impact?`: string, what downstream output is missing or stale, e.g. "64 accounts are missing from this list; next week's report is on hold".
- `retry`: { attempt: number; max: number }, the visible ceiling.
- `onRetry()`, `onFix?()` (reconnect, open settings) and `onDismiss?()`: callbacks. The component never retries on its own.
- `fixLabel?`: string, the label for the real fix, e.g. "Reconnect billing".

### States it must render
- Empty (genuine): "No results. Billing sync last succeeded at 06:00", so a true zero is stated with its freshness.
- Failed: a red notice naming the source, the time, the reason and the impact, with Retry and the fix action; any partial results below are marked as incomplete.
- Retrying: "Retrying, attempt 2 of 3" with buttons disabled.
- Retry exhausted: "Retrying won't fix this" with the cause (e.g. an expired token), Retry removed, and the fix action made primary.
- Recovering: "Reconnected, syncing" with progress; then the notice clears and newly loaded items are briefly marked as "Was missing".

### Interactions
- Retry calls `onRetry` and is disabled once `attempt` reaches `max`.
- When `error.cause` is "auth" or "config", the fix action is primary from the start and Retry is secondary, because retrying cannot succeed.
- Dismiss collapses the notice to a persistent "1 source failing" chip, never removes it while the failure lasts.

### Edge cases
- Partial failure (some records loaded): show the results with an "Incomplete" header and the count missing, not a clean list.
- `lastSuccessAt` is missing: say "Has never synced successfully".
- Several failing sources: stack one line per source with a single summary header, not several full banners.
- Failure that resolves while the notice is open: switch to Recovering rather than vanishing, so the person sees it was fixed.

## Must avoid
Degrading to empty results, so the user reads a broken pipeline as "nothing found".

## Engineering constraint
Distinguish empty-result from error at the API level; retries need a user-visible ceiling.

## Accessibility
- The failed and retry-exhausted states use `role="alert"` once on entry; retry progress is polite.
- The notice is labelled by the source name so a screen-reader user can tell which pipeline broke.

## House rules
- Real `<button>`/`<input>` elements, full keyboard use, visible focus; announce status changes with `aria-live="polite"`; respect `prefers-reduced-motion`.
- All user-facing text comes from props (or a `labels` prop) so it can be translated.
- One consistent accent marks anything the AI made or is doing; amber means "needs a person", red means risky, green means done. Never rely on colour alone.
- Fits a 360 px wide container without horizontal scrolling.

## Acceptance checks
- [ ] Every state above can be rendered by passing props, with no internal fake data.
- [ ] Every interaction and edge case above behaves as described.
- [ ] Nothing in "Must avoid" can happen with this component.

## Deliver
1. The component file with its exported prop types.
2. A short usage example that renders each state.

Download this prompt as Markdown, or every prompt as JSON for an agent.

Critique checklist for dark matter

0 of 4 checked

These questions apply to every pattern in this family. Ticks are saved in this browser.

Can the user find out what ran without being told?
Is background work reversible after the fact?
Do failures surface, or die silently in a log?
Is there one place that lists everything running on the user's behalf?