Serverless Cold Start Load Profile Prompt

This prompt is for serverless performance engineers who need to design a load test scenario specifically targeting the impact of function cold starts. Use it when you have a function's configuration, expected invocation patterns, and latency requirements, and you need a detailed test plan that isolates initialization latency from execution latency. The prompt produces a scenario that mixes concurrent cold start injection with warm invocations, evaluates keep-warm strategies, sets provisioned concurrency thresholds, and defines the latency distribution analysis you will run after the test.

The ideal user brings concrete context: the function's memory and timeout settings, the runtime and package size, the expected steady-state requests per second, and the latency budget for the 95th and 99th percentiles. The prompt works best when you can describe the invocation pattern—whether it's bursty, steady, or event-driven—and when you know which upstream services trigger the function. Without this context, the generated scenario will be generic and may miss the specific cold start behavior that matters for your workload.

Do not use this prompt for general API load testing, database saturation testing, or testing systems where cold starts are not the primary performance concern. It is not designed for container-based deployments where initialization happens at the orchestrator level, nor for functions with negligible initialization overhead where cold start latency is dominated by other factors. If your goal is to test throughput limits, connection pool exhaustion, or downstream dependency saturation, use a different load profile prompt from this pillar. After generating the scenario, validate it against your function's actual cold start traces before executing the test—the prompt produces a plan, not a guarantee.

This prompt template is designed to be pasted directly into your AI assistant. It instructs the model to act as a senior performance engineer and produce a detailed cold start load profile for a serverless function. The output is a structured scenario document that you can hand off to your load testing tooling or use as a specification for test script development. Replace every square-bracket placeholder with the specific details of your function, its runtime, and your performance requirements before running the prompt.

markdownCopy
You are a senior performance engineer specializing in serverless architectures. Your task is to design a cold start load profile for a serverless function to evaluate its initialization impact under realistic production conditions.

## FUNCTION DETAILS
- Function Name: [FUNCTION_NAME]
- Runtime: [RUNTIME] (e.g., Node.js 20, Python 3.12, Java 21)
- Memory Configuration: [MEMORY_MB] MB
- Timeout Configuration: [TIMEOUT_SECONDS] seconds
- Typical Invocation Payload: [PAYLOAD_SCHEMA_OR_EXAMPLE]
- Provisioned Concurrency (if any): [PROVISIONED_CONCURRENCY_COUNT]
- Keep-Warm Strategy (if any): [KEEP_WARM_STRATEGY_DESCRIPTION]

## TRAFFIC PATTERN CONTEXT
- Steady-State RPS: [STEADY_STATE_RPS]
- Peak RPS: [PEAK_RPS]
- Typical Burst Multiplier: [BURST_MULTIPLIER]
- Invocation Pattern: [INVOCATION_PATTERN] (e.g., API Gateway, SQS, EventBridge, direct invoke)
- Expected Cold Start Ratio: [COLD_START_RATIO] (e.g., 5% of invocations)

## PERFORMANCE REQUIREMENTS
- p50 Latency Budget: [P50_MS] ms
- p95 Latency Budget: [P95_MS] ms
- p99 Latency Budget: [P99_MS] ms
- Time-to-First-Response Target: [TTFR_MS] ms
- Error Rate Threshold: [ERROR_RATE_PERCENT]%

## OUTPUT REQUIREMENTS
Produce a load profile document with the following sections:

1. **Scenario Summary**: A one-paragraph description of the test scenario, its objectives, and the hypothesis being tested.

2. **Load Injection Profile**: A detailed table with columns for Phase, Duration, Concurrent Cold Starts, Warm Invocation Rate, Total RPS, and Ramp Rate. Include at least four phases: baseline warm traffic, cold start injection burst, mixed warm/cold sustained load, and cool-down.

3. **Cold Start Injection Strategy**: Describe exactly how cold starts will be triggered (e.g., new container instances, environment variable changes, deployment triggers). Specify the timing and concurrency of cold start injection relative to warm traffic.

4. **Keep-Warm Strategy Evaluation**: If a keep-warm strategy is provided, design a sub-scenario to test its effectiveness. Include metrics to compare: cold start frequency with and without keep-warm, latency distribution shift, and cost impact (provisioned concurrency spend vs. cold start penalty).

5. **Provisioned Concurrency Threshold Analysis**: Recommend specific provisioned concurrency levels to test (e.g., 0, 50% of peak, 100% of peak, 150% of peak) and the expected behavior at each level. Include a hypothesis for the point of diminishing returns.

6. **Latency Distribution Analysis Plan**: Define the latency metrics to collect (p50, p95, p99, max, standard deviation) segmented by start type (cold vs. warm). Specify how to visualize the bimodal distribution and what constitutes an unacceptable cold start penalty.

7. **Monitoring and Observability Checklist**: List the specific CloudWatch/X-Ray/Datadog metrics, dimensions, and log queries needed during the test. Include initialization duration, invocation duration, billed duration, and error counts.

8. **Pass/Fail Criteria**: Define explicit, measurable pass/fail gates for each phase. Include thresholds for cold start latency, warm latency degradation, error rate, and timeout frequency.

9. **Risks and Assumptions**: List assumptions about the test environment (e.g., no other tests running, warm pool state) and risks that could invalidate results (e.g., platform-level cold start rate changes, noisy neighbor effects).

## CONSTRAINTS
- Do not recommend testing at a scale that would exceed typical production traffic by more than 3x.
- If provisioned concurrency is set to zero, explicitly state that all invocations may experience cold starts and adjust the profile accordingly.
- Include a warning if the memory configuration is below 512 MB, as this can artificially inflate cold start duration.
- Flag any SLA targets that are mathematically impossible given the runtime's typical cold start duration range.

After pasting the template, fill in every placeholder with concrete values from your function's configuration and performance requirements. If a placeholder is not applicable—for example, you have no keep-warm strategy—replace the description with 'None' and the model will skip that sub-scenario. The output is a specification document, not executable code. Use it as the design artifact before writing your load test scripts in k6, Artillery, Locust, or your preferred tool. For high-risk production validation, have a second performance engineer review the profile for unsafe assumptions before execution.

This prompt is designed to be called programmatically as part of a performance test design workflow, not as a one-off chat interaction. The primary integration point is a test planning service or CLI tool that collects system architecture metadata, function configuration, and traffic expectations, then invokes the LLM to produce a structured load profile. The output should be treated as a draft workload model that requires validation against real invocation traces and provisioned concurrency limits before it drives load generation tools like Artillery, k6, or Locust.

Wrap the prompt in a function that supplies the required placeholders: [FUNCTION_CONFIG] should include runtime, memory allocation, initialization code characteristics, and any provisioned concurrency settings. [TRAFFIC_PATTERN] needs invocation rate, burst frequency, and the expected ratio of warm to cold starts derived from historical CloudWatch or Datadog metrics. [CONSTRAINTS] should specify the target percentile latency budget (e.g., p99 < 500ms) and any keep-warm strategy already in place. The LLM call should use a model with strong structured output capabilities (Claude 3.5 Sonnet or GPT-4o) with response_format set to JSON and a schema that enforces the output shape: an array of scenario phases, each containing phase_name, duration_seconds, target_rps, cold_start_percentage, expected_p99_ms, and keep_warm_recommendation. Implement a retry wrapper with up to 3 attempts if the output fails JSON schema validation or if the cold start percentages across phases don't sum to a coherent profile. Log each attempt's raw output and validation errors for debugging prompt drift.

Before feeding the generated profile into a load testing tool, run a set of automated evals: verify that the cold start injection rate doesn't exceed what the function's provisioned concurrency can absorb without queueing, check that the ramp-up period allows for realistic initialization time, and confirm that the mix of warm and cold starts reflects actual invocation patterns rather than an artificial worst case. If the profile includes keep-warm strategy recommendations, flag any suggestion that would increase cost by more than 30% for human review. Store the validated profile alongside the function's infrastructure-as-code definition so it can be versioned and re-executed when runtime, memory, or init code changes. Avoid using this prompt for functions with sub-millisecond initialization requirements where cold start impact is negligible—the overhead of generating and validating the profile would exceed its value.