Availability monitoring and load testing: do not confuse the goals

A monitor sends the minimum requests at intervals. A load test controls VUs, iterations, or RPS during an agreed window.

For monitoring, define interval, timeout, one bounded recheck, and maximum requests per hour. For load testing, keep a separate stages or arrival-rate profile and run it only during an authorized window. Separate schedules and service accounts technically so a cron mistake cannot turn an availability check into an unplanned stress test.

Monitoring focuses on availability and response correctness. Load testing adds percentiles, error rate, throughput, and resource consumption.

Evaluate monitoring by windowed availability, response correctness, and detection time. Evaluate load tests by actual RPS, error rate, percentiles, and resource use at each stage. A shared dashboard may show both, but labels and units must remain distinct. Average latency without a distribution and request volume is not a meaningful comparison.

A monitor raises an event and performs a bounded recheck. A load test stops ramping when a stop condition triggers to avoid worsening degradation.

After failure, a monitor opens one incident, performs an independent recheck, and suppresses duplicates until state changes. A load scenario stops ramping immediately and may terminate the run. Never let retries compensate for failure by increasing traffic. Preserve the first event, stop reason, and operator actions in the report.

A lightweight user-flow monitor suits a mobile route. Heavy traffic over a shared mobile route requires a separate objective and capacity plan.

Set a dedicated connection and bandwidth budget for a shared mobile route. Spread lightweight probes with jitter and run heavy tests on reserved capacity or an isolated environment. If most of a location degrades together, pause automatic switching and confirm incident scope through an independent path first.