How to read these results

Each run is one load test against the POS API. A test pushes a growing amount of traffic at the server and records how it responds. The goal is to find the point where the server starts to struggle — the breaking point — so we know the fleet's real limits before customers do.

A run's headline result is one of:

• Passed — met every performance target that was set.
• Missed targets — completed, but one or more targets were exceeded.
• Hit a limit — stopped early because the server got too slow or started failing.
• Completed — ran to the end; no pass/fail targets were set.

p50 / p95 / p99	95 out of 100 requests finished faster than this. When p95 climbs while p50 stays flat, the system is starting to queue under load.
Throughput	Requests per second the server handled — the throughput.
Error rate	The percentage of requests that failed (a bad HTTP status, a business error in the body, a timeout, or a dropped connection).

health-baseline	Ramps plain requests against the health endpoint to find the server's raw request-per-second ceiling — the upper bound everything else lives under.
fleet-poll	Simulates a fleet of tills checking in for settings every 20 seconds, like real devices do. Shows how many devices the server comfortably supports.
settings-push-storm	An operator pushing setting changes to many tills at once while the fleet keeps checking in — does bulk remote management slow the devices' normal sync?
admin-fleet-list	How the portal's device-list pages slow down as the number of known devices grows, since those pages read every device record on each view.
cached-feed	Ramps the cached feeds every till asks for routinely (advertising, product categories, update policy). Shows the ceiling for routine device chatter.
device-secondary	The device calls that write to databases or read files on every request (ad impressions, update reports, smart screens) — separate from the cached feeds.
update-download	Downloads the current app release the way devices do, checking the file arrives complete and that an interrupted download can resume.
release-rollout	Release day: many tills download a new version at once while the rest of the fleet keeps syncing — does a rollout slow normal operations?
switch-probe	Carefully increases simultaneous requests to the transaction switch (read-only, no money) to find where simultaneous selling starts timing out.
catalog-refresh	The full product re-download a till performs when its catalog is stale — the heaviest single thing one device asks of the server.
voucher-buy-soak	Real (dev) voucher sales end-to-end, to measure how long a complete sale takes and whether the switch stays stable. Uses dev stock; never runs by default.
auth	The automatic sign-in handshake every till performs on startup, which also writes to the accounts database on each call.

httpError	The server answered with a failure status (not 2xx).
bodyError	The server answered OK at the HTTP level but reported a business failure in the response — check the detail column (often a declined PIN, an out-of-stock product, or an unactivated account).
softEmptyCatalog	The product catalog came back empty without an error — a known switch behaviour under load, tracked separately because it isn't a real failure.
timeout	The request took longer than the allowed time and was given up on.
connectionError	The connection was refused or dropped — the server or switch wasn't accepting the request.
shapeError	The response couldn't be understood (unexpected format, or — for downloads — a checksum mismatch).
loadShed	The test itself held back a request because too many were already in flight — a sign the server can't keep up at this rate.

Mark a good run as the baseline for its scenario. Later runs are automatically compared to it:

• Unexpected degradation — a run got meaningfully slower at the same load. This is a regression worth investigating.
• Expected — load changed — the run was slower, but it also used more load (e.g. more devices), so the slowdown is normal.
• Improved — faster than the baseline.