Performance Test Results Interpretation Prompt

This prompt is designed for performance engineers and release coordinators who need to convert raw load test results into a structured interpretation report. It compares observed metrics against SLA thresholds, identifies performance regressions, explains anomalies, and produces a clear recommendation on whether performance characteristics support a production release. Use this prompt when you have completed a load test run and need a consistent, evidence-backed analysis that can feed into a broader release readiness assessment. It assumes you already have aggregated metrics from tools like JMeter, k6, Gatling, or Locust, and that SLA thresholds are defined. This prompt does not design load test scenarios or execute tests; it interprets results after the fact.

The ideal user is a performance engineer, QA lead, or release coordinator who has access to structured test results and defined performance SLAs. The required context includes: aggregated percentile response times, throughput, error rates, and resource utilization metrics; explicit SLA thresholds for each metric; and a baseline or prior run for comparison if regression detection is needed. The prompt works best when metrics are pre-aggregated and normalized—do not feed raw log streams or unprocessed JMeter CSV exports directly. Instead, provide summary statistics (p50, p95, p99, mean, max) alongside SLA values and any known environmental conditions that may have influenced results.

Do not use this prompt when you need to design a load test scenario, execute a test, or analyze real-time streaming metrics. It is not a replacement for a monitoring dashboard or an alerting system. The prompt also should not be used to make the final release decision in isolation—its output is an interpretation report that feeds into a broader release readiness assessment. In regulated or high-risk environments, always pair the prompt's output with human review and cross-reference against other quality gate signals such as defect counts, coverage gaps, and incident history before finalizing a go/no-go recommendation.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a senior performance engineer, synthesizing load test results, SLA thresholds, and historical baselines into a defensible interpretation report. The output is not just a summary of numbers; it's a risk-informed recommendation on whether the system's performance characteristics support a production release. All square-bracket placeholders must be replaced with real data before execution. The template is structured to enforce evidence-based reasoning and explicit uncertainty handling.

codeCopy
You are a senior performance engineer evaluating load test results for a release readiness decision.

Your task is to produce a structured interpretation report based on the provided data. You must compare results against defined SLA thresholds, identify performance regressions by comparing against historical baselines, explain any observed anomalies, and provide a clear, evidence-backed recommendation on whether the performance characteristics support proceeding with the release.

# INPUT DATA

## Current Test Results
[PERFORMANCE_TEST_RESULTS]

## Service Level Agreement (SLA) Thresholds
[SLA_THRESHOLDS]

## Historical Baseline Metrics (for regression detection)
[HISTORICAL_BASELINE]

## Context and Test Environment Details
[TEST_CONTEXT]

# OUTPUT SCHEMA
You must respond with a single valid JSON object conforming to this structure:
{
  "executive_summary": "A 2-3 sentence summary of overall performance health and the primary release recommendation.",
  "sla_compliance": {
    "status": "PASS | FAIL | WARN",
    "violations": [
      {
        "metric": "string",
        "threshold": "number",
        "observed_value": "number",
        "severity": "CRITICAL | HIGH | MEDIUM | LOW"
      }
    ]
  },
  "regression_analysis": [
    {
      "metric": "string",
      "baseline_value": "number",
      "current_value": "number",
      "percent_change": "number",
      "assessment": "REGRESSION | IMPROVEMENT | NOISE",
      "explanation": "string"
    }
  ],
  "anomaly_report": [
    {
      "metric": "string",
      "observed_behavior": "string",
      "potential_causes": ["string"],
      "recommended_action": "string"
    }
  ],
  "release_recommendation": {
    "decision": "GO | NO_GO | CONDITIONAL_GO",
    "confidence": "HIGH | MEDIUM | LOW",
    "rationale": "A paragraph linking the decision to specific evidence from the SLA, regression, and anomaly analyses.",
    "conditions": ["A list of specific conditions to be met if the decision is CONDITIONAL_GO."],
    "residual_risks": ["A list of performance risks that remain even if the release proceeds."]
  }
}

# CONSTRAINTS
- Base every conclusion strictly on the provided input data. Do not invent metrics or thresholds.
- If a metric is missing from the input, exclude it from the analysis rather than guessing.
- When comparing to historical baselines, treat a deviation of less than [NOISE_THRESHOLD_PERCENT]% as noise unless it's part of a clear trend.
- For any NO_GO or CONDITIONAL_GO recommendation, you must cite the specific SLA violation or regression that is the primary blocker.
- Use the "explanation" and "rationale" fields to make your reasoning auditable.

To adapt this template, replace the placeholders with your actual data payloads. [PERFORMANCE_TEST_RESULTS] should contain the raw metrics from your load testing tool (e.g., p95 latency, throughput, error rate). [SLA_THRESHOLDS] must define the pass/fail boundaries for each metric. [HISTORICAL_BASELINE] is critical for regression detection; provide the same metrics from the last stable release. [TEST_CONTEXT] should include environment details, test duration, and load profile. The [NOISE_THRESHOLD_PERCENT] variable allows you to tune the sensitivity of regression detection to avoid flagging normal variance. After pasting the prompt, validate that the model's JSON output strictly conforms to the provided schema before feeding it into any downstream release gating automation.

This prompt is designed to sit inside a release readiness pipeline, not as a one-off chat interaction. The primary integration point is after a performance test run completes and raw metrics (latency percentiles, throughput, error rates, resource saturation) are available in a structured format. The application harness should collect these metrics, combine them with the relevant SLA thresholds and historical baseline data, and inject them into the prompt's [PERFORMANCE_TEST_RESULTS], [SLA_THRESHOLDS], and [BASELINE_COMPARISON] placeholders. The model's output—a structured interpretation report—should then be parsed and fed into a downstream release decision aggregator or a human review queue. Do not use this prompt for real-time monitoring alerts; it is designed for batch interpretation of a completed test run against a known release candidate.

The implementation must enforce strict input validation before the prompt is assembled. The [PERFORMANCE_TEST_RESULTS] input should be a pre-validated JSON object containing at minimum: test duration, virtual user count, p50/p95/p99 latency, requests per second, error rate percentage, and peak CPU/memory for each service. The harness should reject the run if required fields are missing or if the error rate exceeds a catastrophic threshold (e.g., >50%), as the prompt's interpretation would be meaningless. After the model returns its output, validate the response against the expected [OUTPUT_SCHEMA]—a JSON object with regression_flags, sla_violations, anomaly_explanations, and a release_readiness_signal enum of SUPPORT, WARN, or BLOCK. If the output fails schema validation, implement a single retry with a repair prompt that includes the validation error. If the retry also fails, escalate to a human performance engineer and log the raw metrics and partial output for diagnosis. For model choice, prefer a model with strong structured output capabilities and a large context window (e.g., GPT-4o or Claude 3.5 Sonnet) to handle verbose test logs if included in [ANOMALY_EVIDENCE].

Logging and observability are critical because this prompt directly influences a go/no-go decision. Log the full prompt, the model's raw response, the parsed output, and the validation result to an immutable audit store. This creates a traceable record for post-release reviews or incident investigations. Avoid wiring the model's release_readiness_signal directly to an automated deployment switch without a human-in-the-loop review step, especially for high-risk services. The harness should present the interpreted report alongside the raw metrics in a review dashboard, allowing a QA lead or release manager to confirm or override the recommendation. The most common production failure mode is a mismatch between the baseline period and the current test conditions (e.g., comparing a peak-hour test against a low-traffic baseline), which the prompt attempts to flag, but the harness should also pre-check that the [BASELINE_COMPARISON] window is explicitly labeled and relevant.