API Load Profile Design Prompt from SLA Requirements

This prompt is designed for performance engineers and SREs who are handed a set of Service Level Agreement (SLA) documents, availability targets, and latency commitments, and need to translate them into a concrete load model. The core job-to-be-done is bridging the gap between business-level reliability promises and the technical parameters required to build a performance test harness. Instead of guessing at throughput targets or request distributions, you provide the raw specification text, and the prompt produces a structured workload profile with per-endpoint throughput targets, percentile latency budgets, and a request mix distribution.

The ideal user has access to formal SLA documentation but does not yet have production traffic traces to replay. This prompt works from specification documents, not from observed data. If you already have access to production traffic logs, API gateway metrics, or distributed tracing data that can be replayed or modeled directly, this is the wrong tool—use a traffic replay or trace-driven modeling approach instead. The prompt is most valuable during the design phase of a new service, when onboarding a third-party dependency with contractual SLAs, or when a business stakeholder provides updated reliability commitments that must be reflected in performance test plans before the next release cycle.

To use this effectively, gather all relevant SLA artifacts: endpoint-level latency percentiles (p50, p95, p99), availability targets (e.g., 99.9% uptime), throughput commitments (requests per second per endpoint), and any error budget definitions. The prompt will identify gaps in your SLA coverage—such as missing endpoints, undefined error rate budgets, or unrealistic concurrency assumptions—and flag them before they become production incidents. After generating the workload profile, validate the output against your system's actual topology and capacity constraints, and use it as the input to your load testing tool's scenario configuration.

The prompt below is designed to be pasted directly into your AI workspace. It takes your service-level agreements, endpoint list, and throughput targets as structured inputs and produces a workload model that a performance engineer can immediately use to configure a load testing tool. Replace every square-bracket placeholder with your actual data before running the prompt. The template enforces a strict output schema so the result can be parsed by downstream automation, not just read by a human.

textCopy
You are a performance engineering assistant. Your task is to translate SLA requirements into a concrete API load profile.

## INPUT
[SLA_DOCUMENT]

## ENDPOINT LIST
[ENDPOINT_LIST]

## THROUGHPUT TARGETS
[THROUGHPUT_TARGETS]

## CONSTRAINTS
- Assume a [TEST_DURATION] test window.
- Target environment: [ENVIRONMENT_TYPE].
- Maximum acceptable error rate: [MAX_ERROR_RATE]%.
- User ramp-up period: [RAMP_UP_MINUTES] minutes.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "load_profile_name": "string",
  "total_target_rps": number,
  "request_mix": [
    {
      "endpoint": "string",
      "method": "GET|POST|PUT|DELETE|PATCH",
      "weight_percent": number,
      "target_rps": number,
      "p95_latency_budget_ms": number,
      "p99_latency_budget_ms": number,
      "request_payload_bytes": number,
      "response_payload_bytes": number,
      "depends_on": ["string"]
    }
  ],
  "ramp_profile": {
    "start_rps": number,
    "end_rps": number,
    "ramp_duration_seconds": number,
    "steps": [
      {
        "duration_seconds": number,
        "target_rps": number
      }
    ]
  },
  "validation_checks": [
    {
      "check": "string",
      "status": "pass|fail|warning",
      "detail": "string"
    }
  ],
  "coverage_gaps": ["string"],
  "assumptions": ["string"]
}

## INSTRUCTIONS
1. Parse the SLA document to extract explicit latency, availability, and throughput commitments per endpoint or endpoint class.
2. Map each endpoint from the endpoint list to its SLA commitments. If an endpoint has no explicit SLA, flag it as a coverage gap.
3. Calculate the request weight distribution so that the sum of all weights equals 100% and the total target RPS matches the throughput target.
4. Assign latency budgets (p95 and p99) per endpoint based on SLA terms. If the SLA only specifies an average, derive conservative percentile budgets and note the assumption.
5. Identify dependencies between endpoints (e.g., a POST that must follow a GET to obtain a resource ID) and list them in the `depends_on` field.
6. Design a ramp profile that starts at 10% of target RPS and reaches 100% over the ramp-up period, with at least 3 steps.
7. Run validation checks: confirm weight percentages sum to 100%, confirm latency budgets do not exceed SLA limits, confirm all listed endpoints appear in the request mix, and flag any endpoint with zero RPS allocation.
8. List any coverage gaps where the SLA is silent on an endpoint or metric.
9. List all assumptions made during the design (e.g., uniform distribution within an endpoint class, no caching effects, steady-state traffic).

Return only the JSON object. Do not include any text outside the JSON.

After pasting the template, replace [SLA_DOCUMENT] with the full text of your SLA or SLO document. Replace [ENDPOINT_LIST] with a structured list of your API endpoints, including HTTP methods and typical payload sizes. Replace [THROUGHPUT_TARGETS] with your target requests-per-second or transactions-per-second figures. The remaining placeholders ([TEST_DURATION], [ENVIRONMENT_TYPE], [MAX_ERROR_RATE], [RAMP_UP_MINUTES]) are scalar values that tune the output to your test environment. If your SLA document is long, consider splitting it into sections and running the prompt once per service tier to keep the context window manageable.

Before wiring this into an automated pipeline, run the prompt manually against a known SLA and endpoint list. Inspect the validation_checks array in the output—any fail or warning status indicates a problem that needs human review. Pay special attention to coverage_gaps: endpoints without SLA commitments are untestable against a latency budget and may hide production risk. If the output will feed directly into a load generator like k6, Locust, or JMeter, add a post-processing step that converts the JSON into the tool-specific script format and validates that all depends_on relationships are executable in the correct order.

This prompt is designed to be the first step in a multi-stage performance engineering pipeline. It translates a human-readable SLA document into a structured, machine-readable load profile. The output is not a final test script; it is a specification that must be validated before being fed into a load generation tool like k6, Locust, or JMeter. The primary integration point is an automated workflow where an SRE or performance engineer uploads an SLA document, the prompt generates a JSON profile, and a downstream validator checks the profile for internal consistency and coverage gaps before any test execution begins.

Wire the prompt into an application by first extracting the SLA text from its source format (PDF, Confluence, or a text field). Pass this text as the [SLA_DOCUMENT] input. The model should be instructed to produce a strict JSON output conforming to a predefined schema. Use a model with strong JSON mode and structured output support, such as gpt-4o or claude-3-opus, with a low temperature setting (0.1-0.2) to maximize determinism. After receiving the response, a validation layer must parse the JSON and run a series of checks: confirm that every endpoint listed in the SLA has a corresponding entry in the profile, verify that the sum of request mix percentages equals 100, and flag any throughput target that implies a concurrency level exceeding the SLA's stated maximum. If validation fails, the application should not proceed to test generation; instead, it should log the failure, capture the raw output, and either retry with a more explicit prompt or escalate for human review.

Implement a retry strategy for cases where the model output fails schema validation or the coverage checks. On the first failure, re-invoke the prompt with the original input and an additional [CONSTRAINT] that explicitly calls out the specific validation error (e.g., 'The request mix percentages do not sum to 100. Recalculate and ensure they total exactly 100%'). Limit retries to a maximum of two attempts to avoid infinite loops. If the output still fails, route the task to a human-in-the-loop queue with the original SLA, the failed outputs, and the specific validation errors highlighted. For logging, capture the model version, prompt template version, input SLA hash, and validation pass/fail status for every run. This traceability is critical for auditing why a particular load profile was generated and for debugging prompt drift over time. Avoid wiring this prompt directly to a test execution engine without the validation gate; an incorrect load profile can waste compute resources, create misleading test results, or even cause a production-impacting overload if safety limits are not enforced.