Pair k6 load with inbox checks for password-reset email

A password-reset endpoint can stay fast while its email queue falls behind. To catch that failure, a load test needs two observations: how the application responds under pressure, and whether a reset message reaches an inbox afterward.

Use k6 to generate requests against a staging reset flow, and InboxRhino's receive-only test inboxes to check selected messages. Keep those jobs separate. If every virtual user also waits on an inbox API, the test starts measuring mailbox polling and inbox quotas alongside the application. That makes the result harder to interpret.

Set up a bounded test

First, point the staging environment at a test-safe email configuration. Use test accounts and addresses only; do not let a stress run send password-reset messages to real customers. Keep the request pattern representative: a mix of valid test accounts and whatever invalid-input cases your application needs to handle. Do not share one live account across concurrent requests if that would trigger throttling or change the flow you intend to measure.

In k6, record the reset-request response time and status for each request. Those are application measurements. Choose a load profile that matches the question you are asking, such as whether the service remains responsive as request volume rises. The exact traffic level and acceptable thresholds depend on your system, so set them before the run rather than treating a successful script exit as proof of reliability.

For email checks, create a small, separate set of InboxRhino addresses at test.inboxrhino.in. The API supports creating inboxes and waiting for messages with subject and sender filters. Give test messages a distinctive subject or sender where your application allows it. If the reset flow uses a fixed subject, use a fresh inbox for each checked transaction when your available inbox count permits; an old matching message can otherwise make a check ambiguous.

Load the app, verify a sample

1. Have k6 issue the reset requests and record which sampled requests should produce email. Keep the sample deliberately small relative to the full load.

2. After those requests, have a separate verification step call InboxRhino's wait-for-message API for each sampled inbox, applying the available subject or sender filter. The API can wait up to 180 seconds. Record elapsed time from the request to the completed inbox check, but label it as observed end-to-end detection time, not a precise mail-server delivery timestamp.

3. Check that each sampled message arrived and that its contents match the expected reset flow. For visual inspection of HTML, InboxRhino provides a sandboxed viewer that blocks scripts, forms, popups and remote images. The inboxes cannot send, reply to or forward messages.

4. Report the two result sets separately: k6 response behavior for the whole load, and message arrival and content checks for the sample. A missing sampled message is a signal to investigate the dispatch path; it does not, by itself, identify whether the application, queue or downstream mail delivery caused the failure.

Keep quotas in the test plan

Inbox capacity is a practical constraint, not an unlimited sink for load traffic. InboxRhino's free tier includes 11 active inboxes and 33 inbound emails per month, with one organisation user. Starter provides 1,100 active inboxes and 3,300 emails per month through an access code. Growth and Scale are planned tiers, not a basis for assuming currently available capacity. Check the current terms before scheduling a larger run. The paper's quota guide to inbox testing gives more context on how these limits shape test design.

Do not create one inbox or request one email check for every virtual user unless the available inbox and email quotas support that plan. A sampled check is cheaper, but it cannot prove that every message in the run arrived. A useful compromise is to verify a few messages at each load stage and run a separate, lower-volume test when you need broader end-to-end coverage. Include the number of checks and the coverage gap in the report.

InboxRhino retains messages for 30 days before deletion. That helps with reviewing a run after it finishes, but it is not a permanent test archive. Save the results your team needs elsewhere, and avoid putting sensitive production data into test messages.

Know what the result says

This stack tests a real incoming email path, not just whether the reset endpoint returned success. It also has boundaries: the wait call may remain open for up to 180 seconds, inbox quotas limit how many checks fit, and a sampled result is not a census of all messages. Keep mailbox verification outside the k6 request path, make the sample explicit, and separate application latency from email arrival checks. That gives performance engineers useful evidence without mistaking inbox polling for application load.