Performance exit conditions
Candidate exit conditions for the Performance type. See the catalog overview for how to adopt these.
Response latency
| Exit condition | What it checks |
|---|---|
|
Median (p50) response time for the endpoint stays at or below the target budget under nominal load. |
|
The 95th-percentile response time stays at or below its target budget under nominal load. |
|
The 99th-percentile response time stays at or below its target budget under nominal load. |
|
Extreme tail latency (p99.9) stays within a defined ceiling so worst-case requests remain bounded. |
|
No individual request exceeds a hard maximum latency ceiling during the measured window. |
|
Percentile latency targets still hold when the system is driven at its rated concurrency, not just at idle. |
|
First-request (cold-start) latency after a deploy or scale-out stays within an allowed budget. |
|
Server time-to-first-byte for the endpoint stays under the target threshold. |
|
Measured latency does not regress beyond an allowed delta versus the recorded baseline. |
Throughput and capacity
| Exit condition | What it checks |
|---|---|
|
The service sustains the target requests-per-second without error-rate or latency breach over a sustained window. |
|
The service absorbs the specified peak requests-per-second burst without failing requests. |
|
Throughput normalized per CPU core meets the efficiency target for the workload. |
|
The measured saturation (knee) point occurs at or above the required load level. |
|
The ratio of successfully completed requests to total offered load stays above the target under load. |
|
Sustained write operations per second meet the target for the persistence path. |
|
Sustained read operations per second meet the target for the query path. |
|
Batch or bulk jobs process records at or above the required rate per unit time. |
|
A backlog of queued work drains at a rate that keeps end-to-end lag within the target. |
Resource utilization
| Exit condition | What it checks |
|---|---|
|
Steady-state CPU utilization stays within the allocated budget at the rated load. |
|
Resident memory stays below the configured ceiling under sustained load. |
|
Memory usage returns to baseline after load and shows no upward drift across a soak run. |
|
Maximum garbage-collection pause time stays within the allowed budget. |
|
The fraction of wall-clock time spent in garbage collection stays below the target ratio. |
|
Peak heap usage leaves the required headroom below the maximum heap size under load. |
|
Open file-descriptor and socket counts stay within the configured limit under load. |
|
Thread-pool saturation stays below the threshold that would cause queuing or starvation. |
|
Disk read/write IOPS and bandwidth stay within the provisioned budget under load. |
Scalability and autoscaling
| Exit condition | What it checks |
|---|---|
|
Throughput scales near-linearly as replicas are added, within the target efficiency factor. |
|
Time from a scaling trigger to new capacity serving traffic stays within the target. |
|
Scaling in does not drop in-flight requests or breach latency targets during downscale. |
|
Autoscaling fires at the configured utilization threshold before saturation is reached. |
|
The system meets required total capacity at the maximum configured replica count. |
|
Added capacity yields the expected marginal throughput gain rather than diminishing returns. |
|
Autoscaler does not thrash (rapid scale up/down cycles) under a steady load pattern. |
|
Reserve capacity is sufficient to absorb a spike while new replicas are still starting. |
Data access and caching efficiency
| Exit condition | What it checks |
|---|---|
|
A request path issues no N+1 query pattern, verified by query-count assertions per operation. |
|
Individual database query latency stays within its target budget under load. |
|
Hot query paths are served by an index and do not fall back to full scans. |
|
The connection pool is sized to sustain target concurrency without excess idle connections. |
|
Connection-pool wait time and exhaustion events stay within limits under peak load. |
|
No query exceeds the slow-query threshold during the measured load window. |
|
The number of database round-trips per request stays at or below the target. |
|
Cache hit rate for the cached surface meets or exceeds the target percentage under representative load. |
|
Concurrent misses for a hot key do not trigger a stampede of duplicate backend work. |
|
List and query endpoints enforce pagination or result caps rather than returning unbounded sets. |
|
Response payload size stays within the target byte budget for the endpoint. |
Concurrency and backpressure
| Exit condition | What it checks |
|---|---|
|
The service enforces a bounded in-flight concurrency limit rather than accepting unlimited work. |
|
Under overload the system applies backpressure to upstream producers instead of buffering unboundedly. |
|
Internal queue depth stays below its configured ceiling under sustained load. |
|
No stage in the request or stream path uses an unbounded in-memory buffer. |
|
Resource pools are bulkheaded so saturation of one dependency does not starve unrelated paths. |
|
Per-client or per-endpoint rate limits are enforced at the configured threshold. |
|
Beyond capacity the system sheds load with fast rejections rather than degrading all requests. |
|
Outbound calls enforce timeouts within budget so slow dependencies cannot pile up in-flight work. |
|
Blocking work is isolated so it does not starve the shared execution or event-loop threads. |
Akka runtime performance
| Exit condition | What it checks |
|---|---|
|
A single entity sustains the target command throughput without breaching its latency budget. |
|
Entity command round-trip latency stays within its percentile budget under load. |
|
Aggregate entity throughput scales as shards are distributed across added nodes. |
|
Shard rebalancing during scale events keeps latency impact within the allowed transient budget. |
|
View query latency meets its percentile target under representative query load. |
|
View projection lag behind source events stays within the target eventual-consistency window. |
|
A stream or consumer processes events at or above the required sustained rate. |
|
Consumer offset lag stays within the target bound under peak inbound event rate. |
|
Entity passivation keeps the active in-memory set and memory footprint within budget under a large key space. |
Load, soak, and stress testing
| Exit condition | What it checks |
|---|---|
|
A load test at target load passes all latency, throughput, and error-rate thresholds. |
|
An extended soak run holds latency, throughput, and resource metrics stable without drift. |
|
Under a ramping stress test the breaking point occurs at or above the required load level. |
|
After a traffic spike the system returns to baseline latency within the target recovery time. |
|
Beyond capacity the system degrades gracefully rather than collapsing or cascading failures. |
|
A performance regression test gates the build when key metrics regress past the allowed delta. |
|
Measured capacity leaves the required headroom above expected peak production load. |
|
Over an endurance run there is no monotonic drift in latency, memory, or connection counts. |
Frontend performance
| Exit condition | What it checks |
|---|---|
|
UI-only: Largest Contentful Paint stays within the Core Web Vitals target for the page. |
|
UI-only: Interaction to Next Paint stays within the responsiveness target for key interactions. |
|
UI-only: Cumulative Layout Shift stays below the visual-stability target for the page. |
|
UI-only: First Contentful Paint occurs within the target time on the reference network profile. |
|
UI-only: Time to Interactive stays within the target so the page becomes usable promptly. |
|
UI-only: The shipped JavaScript bundle size stays within the byte budget after compression. |
|
UI-only: Total main-thread blocking time stays below the target to avoid input jank. |
|
UI-only: Total image and media weight for the page stays within the transfer budget. |