Emergency Case Intake Load and Resilience Testing Brief
Construct a performance and chaos engineering brief to validate disaster intake platforms under catastrophic surge traffic.
Use this template when planning load, stress, and failover tests for public sector emergency management and disaster relief applications before disaster seasons.
Role: Lead Performance & Resilience Engineering Specialist for humanitarian relief and emergency response systems.
Context
- Operating Public Agency: {{agency_department}}
- Emergency Intake Service: {{intake_application_endpoint}}
- Peak Target Throughput: {{peak_applicant_throughput}}
- Hosting Infrastructure Profile: {{cloud_infrastructure_spec}}
- Maximum Latency Threshold: {{max_acceptable_latency_ms}}
- Offline Sync & Failover SLA: {{offline_failover_sla}}
Task
Formulate a load, stress, and chaos engineering test brief that validates the operational stability, autoscaling responsiveness, and offline continuity of {{intake_application_endpoint}} during sudden disaster intake surges for {{agency_department}}.
Method
- Translate historical natural disaster traffic spikes into step-load and sudden-spike load curves targeting {{peak_applicant_throughput}}.
- Define distributed stress vectors testing concurrent photo/document uploads, SMS verifications, and geographic location lookups.
- Specify chaos engineering injection scenarios (e.g., primary database failover, message queue backpressure, CDN cache invalidation) under 80% baseline load.
- Establish latency degradation boundaries evaluating response times against {{max_acceptable_latency_ms}} across degraded cellular networks.
- Design edge-case offline sync verification tests validating data store recovery within {{offline_failover_sla}}.
- Detail synthetic test data generation strategies ensuring volume generation without polluting federal emergency dispatch systems.
- Define telemetry monitoring dashboards, resource saturation thresholds on {{cloud_infrastructure_spec}}, and emergency test abort triggers.
- Formulate a post-test capacity report template to brief municipal executive leadership.
Constraints
- Performance thresholds MUST NOT exceed the bounds set in {{max_acceptable_latency_ms}} under target load.
- Synthetic test runs MUST be quarantined completely from real emergency dispatch webhooks.
- Test scripts MUST simulate realistic field network conditions (e.g., 3G packet loss, high jitter).
- All load vectors must culminate at or above {{peak_applicant_throughput}}.
Output format
- Performance Test Scope & Traffic Models (table with Stage, Virtual Users, Duration, Ramp Profile)
- Resilience & Chaos Test Matrix (4-6 test failure scenarios with expected recovery behaviors)
- Network & Latency Acceptance Gates (bulleted limits referencing {{max_acceptable_latency_ms}})
- Offline Data Integrity Protocol (step-by-step verification process)
- Safety Controls & Abort Triggers (mandatory checklist)
Self-review
- Does the chaos testing plan explicitly verify the {{offline_failover_sla}} recovery timeframe?
- Are the infrastructure parameters in {{cloud_infrastructure_spec}} targeted for bottleneck analysis?
- Is synthetic data handling safely isolated from production emergency channels?
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.