FROM SIGNAL TO NEXT ACTION

A spike is a question.
Evidence decides the follow-up.

Change the evidence behind an HTTP 400 spike. See what deserves a page, a human investigation, or a careful recheck.

Start with a scenario

Then change any signal

01 / COLLECT EVIDENCE

What is actually happening?

5-minute sample

Public API /v1/requests · illustrative traffic

HTTP 400 rateRejected requests / all requests User / client journey successIncludes first-party client failures p95 latencyFor valid requests CPU useService capacity signal Memory useMemory alone is not impact proof

Request rejection Downstream dependencies Security evidence Simulated classifier Evidence consistency

Evidence available and current Application logs / rejection traces Adequate samples: no exception, sensitive response or side effect Resource and dependency metrics User / client journey signals

Illustrative routing thresholds

These values explain this demo; they are not production defaults. The example spike clears at a 400 rate of 2% or below, after all evidence gates pass.

Demo thresholds
Signal	Human review	Page now
Journey success	Below 99%	Below 97%
p95 latency	≥ 800 ms	≥ 1,500 ms
CPU or memory	≥ 75%	≥ 90%
Dependencies	Strained	Unavailable

Only current evidence supports these triggers. Resource-only paging is an illustrative capacity rule; real policy needs duration and headroom. A 400 rate never pages by itself. Real thresholds need service baselines, traffic floors and SLOs.

03 / EXPLAIN THE ROUTE

From event to follow-up

Step Functions workflow · simulated

04 / KEEP THE REASON

Decision journal

This browser session only · latest 10

Run triage to record a decision, its evidence and the next action.

05 / REPLAY EVIDENCE

Test the follow-up

Import ordered evidence snapshots and compare decisions with expected outcomes. Files stay in this browser; imported evidence never changes the sliders above.

Replay JSON