Kubernetes: presupuestos de tiempo para correo en CI

Testing pipelines in Kubernetes often take several minutes, yet end with a useless message like “email not found”. A practical solution is to set a time budget for each stage. The goal is to understand which part consumed the available time so the next incident is less mysterious. The symptom is a timeout that explains nothing.

Consider a test registering in a staging namespace. The form responds 201, but the test waits for the confirmation message for 60 seconds and fails. The team checks the browser log, sees an “email not found” and retries the job. Sometimes it works; other times it doesn't. Retrying is tempting, but it mixes multiple clocks: event publication by the API, event collection by the worker, delivery to the mail provider, message appearing in the test inbox, and reading the message and confirming the link. When all live under a single timeout, the test loses its diagnostic capability.

A SRE needs at least one signal per stage, even if it's a simple one. Define a budget per stage. Start with a table that anyone on the team can understand. For a normal flow of 45 seconds:

Stage Budget Minimum Evidence API publishes the event 2 s request_id and status HTTP Worker collects the event 8 s pod name and counter Provider accepts the delivery 10 s message_id or error Mailbox appears 20 s mailbox_id and received_at Test reads and verifies 5 s final state and exit code

The numbers are not universal. They are an initial contract that can be adjusted with real data. If most deliveries happen in five seconds, a budget of twenty may be reasonable for CI; if the queue takes longer at night, it needs to be measured, not guessed. The test should keep the times for each stage. Don't store the full message content in a public artifact: usually a single identifier, message hash and states are enough. This way the diagnosis helps without filtering test data.

What to observe in Kubernetes When dealing with a mail failure in Kubernetes, check four signals before increasing the timeout: Worker restarts. A restartCount near the time of sending may explain a queue that hasn't progressed. Pod age. If the deployment rotated during the test, the event may have ended up in memory and not been confirmed.

Queue depth. A growing queue with consumers ready indicates pressure; a quiet queue with zero consumers indicates another problem. Correlation. The same request_id should appear in the API, worker, and mail adapter. For a quick check, a diagnostic job might produce something like this: run=ci-1842 request=req-7f2 worker=mail-worker-6d8c api=accepted worker=processed provider=accepted inbox=pending pod_restarts=0 queue_depth=3 elapsed=18s

Seeing “inbox=pending” is much more useful than a generic timeout. If the queue keeps growing, the test shouldn't blame the mailbox yet. A simple implementation in CI uses a monotonic clock and logs a line entering and leaving each stage. The mail adapter should accept an absolute deadline, not restart the counter completely on each poll.

Otherwise, ten attempts of six seconds could turn a twenty-second budget into a minute without being obvious. It's also a good idea to reserve a unique address per execution. A shared mailbox makes it hard to know if the current message arrived or if the test read an old one. In documentation and internal searches, look for terms like tempail or tamp mail com; don't use them to design logic, but you can map them to the correct terminology in the team's search.

When the message doesn't arrive, keep the summary of states and end with a concrete cause: worker-timeout, provider-rejected, inbox-timeout, or verification-timeout. This way a retry can be selective and not repeat the whole suite unnecessarily. For systems with multiple consumers, it's worth formalizing the contract of signals.

An article on mail contracts for automation shows a way to think about events and states without depending on a huge log. For operational alerts, failover alerts that can be tested with observable evidence follow the same idea: an alert must be testable with observable evidence.

Incident checklist Does each stage have a separate budget? Does the test keep request_id, mailbox_id, and message_id without storing unnecessary data? Did the worker restart or lose the lease of the event? Was the queue advancing, blocked, or had no consumers? Was the deadline absolute or restarting on each attempt? Did the final result distinguish delivery, reading, and verification?

A timeout is still a real limitation, but it shouldn't be a vague explanation. With small budgets, correlated signals, and an isolated inbox per execution, Kubernetes and CI can tell you where the problem is before anyone presses "retry".