Soak Test Scenario Construction Prompt

This prompt is for reliability engineers and SREs who need to design a long-running soak test scenario before writing a single line of test script. The job-to-be-done is converting a system's steady-state architecture, known resource limits, and slow-burn failure hypotheses into a concrete, executable test plan. You should use this prompt when you have a clear picture of the target service's normal load profile, its memory and connection pool configurations, and the specific degradation signals you want to monitor over an extended period (typically 6–72 hours). The ideal user brings a service map, recent resource dashboards, and a list of suspected leak or accumulation risks—this prompt will not invent those from scratch.

Do not use this prompt for spike testing, breakpoint discovery, or capacity planning. Those scenarios require different load profiles (rapid ramp, graduated overload, or growth projections) that this prompt's steady-state focus will not produce. Also avoid this prompt if you lack baseline metrics for the target environment; the output requires concrete thresholds for memory growth rate, disk accumulation, and connection count trends. If you feed it vague inputs like 'test for memory issues,' the generated scenario will be too generic to catch the slow-burn failures that distinguish soak tests from shorter-duration performance runs. The prompt assumes you already understand the difference between a memory leak and high baseline memory usage—it will not teach you reliability engineering fundamentals.

This prompt works best when paired with a monitoring harness that can collect the specified trend metrics over the full test duration. Before using the output, validate that your observability stack can track the exact indicators the scenario requests (e.g., heap size delta per hour, file descriptor count slope, connection pool wait time drift). If your monitoring cannot capture these signals at the required granularity, fix that gap first. The scenario will include checkpoints and abort conditions; wire those into your test orchestration so the soak test stops automatically if a threshold is breached, rather than running blind for hours. For high-risk production-facing services, add a human approval gate before starting any soak test that shares infrastructure with live traffic.

After generating the scenario, review the resource trend monitoring criteria against your actual service limits. The prompt will produce thresholds based on the inputs you provide, but it cannot know about undocumented limits or recent config changes. If the output suggests a memory leak threshold of 50MB/hour but your service typically grows 30MB/hour under normal operation, adjust the threshold before execution. The scenario is a starting point for your test design, not a final runbook. Use it to structure your thinking about what 'stable' means for this specific service over time, then adapt the checkpoints and durations to your operational reality.

The following prompt template is designed to be copied directly into your AI harness, notebook, or prompt management system. It uses square-bracket placeholders for all dynamic inputs—system architecture details, known risk areas, monitoring stack, and the required output format. Replace each placeholder with concrete values before execution. The prompt instructs the model to act as a reliability engineer constructing a long-running stability test, focusing on slow-burn failure modes like memory leaks, connection pool exhaustion, and disk accumulation rather than immediate breakpoints.

textCopy
You are a senior reliability engineer designing a long-duration soak test to validate system stability under sustained load.

Your task is to produce a complete soak test scenario based on the provided system context, risk profile, and monitoring capabilities.

## SYSTEM CONTEXT
[SYSTEM_ARCHITECTURE_DESCRIPTION]

## KNOWN RISK AREAS
[KNOWN_RISK_AREAS_AND_PAST_INCIDENTS]

## MONITORING STACK
[MONITORING_TOOLS_AND_AVAILABLE_METRICS]

## TARGET DURATION
[TARGET_SOAK_DURATION_HOURS]

## CONSTRAINTS
[ENVIRONMENT_CONSTRAINTS_AND_LIMITS]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "scenario_name": "string",
  "steady_state_load_profile": {
    "total_throughput_target": "number (requests/second)",
    "request_mix": [
      {
        "endpoint_or_operation": "string",
        "percentage_of_traffic": "number",
        "payload_profile": "string (description of typical payload size and shape)"
      }
    ],
    "ramp_up_period_minutes": "number",
    "steady_state_duration_hours": "number",
    "ramp_down_period_minutes": "number"
  },
  "slow_burn_failure_hypotheses": [
    {
      "failure_mode": "string (e.g., memory leak, connection pool leak, disk accumulation, thread starvation)",
      "affected_component": "string",
      "detection_metric": "string (specific metric name from monitoring stack)",
      "degradation_threshold": "string (value or trend that indicates a problem)",
      "expected_time_to_surface_hours": "number"
    }
  ],
  "resource_trend_monitoring": [
    {
      "resource": "string (CPU, memory, disk, file descriptors, connections, etc.)",
      "component": "string",
      "baseline_start_value": "string (expected value at test start)",
      "maximum_acceptable_growth_rate": "string (e.g., +5MB/hour, +10 connections/hour)",
      "alert_threshold": "string"
    }
  ],
  "log_rotation_checkpoints": [
    {
      "log_source": "string",
      "check_interval_hours": "number",
      "expected_rotation_behavior": "string",
      "failure_indicator": "string (what to look for if rotation fails)"
    }
  ],
  "data_accumulation_checks": [
    {
      "data_store": "string (database table, queue, filesystem path)",
      "expected_growth_pattern": "string",
      "cleanup_mechanism": "string (what should prevent unbounded growth)",
      "warning_threshold": "string"
    }
  ],
  "pass_criteria": [
    "string (specific, measurable condition that must hold for the test to pass)"
  ],
  "abort_conditions": [
    "string (condition that triggers immediate test termination)"
  ]
}

## INSTRUCTIONS
1. Use the SYSTEM CONTEXT to identify components most likely to exhibit slow-burn failures.
2. Cross-reference KNOWN RISK AREAS to ensure past incident patterns are covered.
3. Only reference metrics that exist in the MONITORING STACK.
4. Set degradation thresholds conservatively—soak tests catch trends, not spikes.
5. Include at least one hypothesis for memory, one for connections, and one for disk or data accumulation.
6. If any required field cannot be determined from the provided context, set its value to null and add an entry to an "assumptions" array explaining what additional information is needed.

To adapt this template, replace each square-bracket placeholder with concrete values from your system. The [SYSTEM_ARCHITECTURE_DESCRIPTION] should include service names, data stores, connection pools, and any known resource limits. The [KNOWN_RISK_AREAS_AND_PAST_INCIDENTS] field is critical—soak tests are most valuable when they target failure modes that have already caused outages. If you lack historical incident data, describe the components you suspect are least tested under sustained load. The output schema enforces a structured JSON response suitable for direct ingestion into a test automation harness or runbook. Before executing the generated scenario in production-like environments, validate that every detection metric referenced in the hypotheses actually exists in your monitoring stack and that abort conditions are wired to automated kill switches.

This prompt is designed to be called from a reliability engineering pipeline or a manual QA planning tool, not as a standalone chat interaction. The primary integration point is a function that accepts a system architecture description, known failure modes, and a target duration, then returns a structured soak test plan. Because the output directly influences production stability gates, the harness must validate the plan's completeness before it reaches a human reviewer or an automated test orchestrator.

Integration pattern: Wrap the prompt in a service function generate_soak_scenario(system_context, duration_hours, known_risks). The function should: (1) assemble the prompt with the provided inputs and a fixed [OUTPUT_SCHEMA] that defines the required JSON structure (steady-state load profile, memory leak detection thresholds, log rotation checkpoints, resource trend criteria); (2) call the model with a low temperature (0.1–0.2) and JSON mode enabled to enforce structural consistency; (3) validate the returned JSON against the schema, checking that every required field is present, thresholds are numeric, and checkpoints are time-ordered; (4) on validation failure, retry once with the validation errors appended to the prompt as [CONSTRAINTS] feedback; (5) log the final output, model version, and validation result for auditability. Model choice: Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) because the scenario requires precise numeric thresholds and temporal ordering that smaller models often fumble. Retry logic: Limit to one retry. If the second attempt also fails validation, escalate to a human reliability engineer with the partial output and validation errors flagged—do not silently fall back to a degraded plan.

Human review gate: Even after successful validation, the generated soak test scenario must be reviewed by a reliability engineer before execution. The harness should render the plan in a review UI that highlights: (a) the steady-state load profile with expected resource consumption; (b) each memory leak detection threshold alongside the component it monitors; (c) log rotation checkpoints on a timeline; (d) resource trend criteria with explicit saturation warnings. The reviewer can approve, modify, or reject the plan. Approved plans are serialized and passed to the test orchestrator (e.g., k6, Locust, or a custom soak test harness). Observability: Tag every generated plan with a unique plan_id, the prompt version, model version, and reviewer identity. Store the full prompt, raw model output, validation results, and reviewer decision in a queryable log for post-incident analysis. If a soak test reveals a failure mode the prompt missed, feed that gap back into the [KNOWN_RISKS] input for future generations.

What to avoid: Do not feed the raw model output directly into a test orchestrator without schema validation and human review. Do not use this prompt for short-duration load tests or spike tests—it is specifically tuned for multi-hour soak scenarios where slow-burn failures (connection pool leaks, disk accumulation, memory fragmentation) are the target. Do not skip the retry log; silent failures in soak test design can waste days of test execution time. If the system under test has no historical failure data, explicitly set [KNOWN_RISKS] to an empty list and add a note in the review UI that the plan is based solely on architectural analysis without empirical failure evidence.