Health check data simulation
Skill kjuhwa/skills-hub/skills/workflow/health-check-data-simulation
Self-correcting knowledge corpus for Claude Code — 9 stable shape clusters, bias-correction pipeline baked into contribution flow. 47 papers, 45 techniques, 1.1k skills.
npx -y skills add kjuhwa/skills-hub --skill health-check-data-simulationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate realistic health-check sample streams with correlated failures, flapping, and recovery curves for demos and tests
SKILL.md
1.8 KB, 315 tokens by cl100k_base, as published. Nobody here has run it
health-check-data-simulation
Real health-check data has structure that random booleans don't capture: failures cluster (a downed load balancer takes 5 dependent services with it), flapping is bursty (a service near a memory limit oscillates up/down every few probes before dying for good), and recovery is rarely instant (latency stays elevated for minutes after a restart). Simulate by modeling each probe as a small state machine with states healthy → degrading → down → recovering → healthy and per-state dwell-time distributions, then couple probes via a dependency graph so an upstream down biases downstream transitions toward degrading.
Seed each scenario deterministically (scenario name → PRNG seed) so a demo labelled "cascading-db-failure" produces the same sequence every run — reviewers and tests need reproducibility. Inject three canonical scenarios every health-check demo should ship with: steady-state green (baseline, no failures), single-probe flap (isolates UI behavior on oscillation), and cascading outage (exercises the aggregate banner and dependency visualization). Latency values should be drawn from a log-normal distribution, not uniform — real p99 tails are what stress the layout.
Tick the simulator at a rate decoupled from wall-clock (e.g. 10 simulated probes per real second for demos, 1:1 for tests) and emit each sample through the same ingestion path the real probes use. If the sim bypasses the ingestion pipeline, the UI is effectively untested.