Staging gets pointed at a live service once for a quick check — and nobody switches it back. A month later an automated run creates a dozen real accounts on the live service, and the payment gateway charges real money for a trial order. The incident is not in the run itself — it is that staging and production were never separated at the configuration level. Here is how that happens and what to check so an automated run does not turn into a live incident.
The typical incident: how a test run creates live accounts
The scenario is almost always the same: staging's config was cloned from production, some values were changed, but the API address or access key was left as is. Runs go fine for months — until one of them touches the registration or payment endpoint. Then real accounts with names like test_user_1 show up in the live database, and the payment gateway posts real charges for trial orders.
It is worse if the incident goes unnoticed: those accounts sit in production for weeks, get pulled into analytics, skew conversion metrics, and get mixed up with genuine users during incident review.
Separating staging and production configs by keys and addresses
The reliable way to stop relying on memory is to physically split the configs: staging gets its own set of access keys, its own API address, its own callback domain. A single config file with a "test/prod" switch is the source of most incidents, because the switch can be forgotten or flipped the wrong way during deployment.
It is worth checking the key format against the documentation — for example, the number rental API docs: a staging key and a live key often look almost identical, and the difference only shows up in the prefix or in which section of the account issued the key.
A dedicated pool of numbers and mailboxes for runs
An automated run needs real numbers and mailboxes — there is no other way to check SMS delivery or a confirmation email. The mistake is pulling them from the shared live pool: a number tied up by a run drops out of sale, and after the run it can stay attached to a live account nobody planned to create.
The correct setup is a separate pool marked with a distinct status as soon as it is issued, plus a separate registry for it: the same fields as for live resources — setup, date, state — with its own "test" status. How such a registry works in general is covered in inventory of numbers, mailboxes and IPs.
Signs that staging is pointed at the wrong place
A few signals worth checking before every config release: staging's logs show a live domain or a live address from the API rotation pool; a counter in live analytics grows in step with an automated run; support's live inbox receives auto-replies with test names; the balance on the live wallet drops without any manual action at a moment when only a trial run should be happening.
Any one of these is a reason to stop the run immediately, not a reason to add an "ignore in production" condition to it.
The rule that a test key must not exist in production, and a checklist before the first run
The single most reliable rule is simpler than any monitoring: a staging access key must not physically exist in the production environment, and a live key must not exist in staging. Not "disabled by default" — actually absent, so a misdirected call fails on authorization instead of reaching the live service.
Before the first automated run, check four things: the API address and access key in staging's config were not copied from production; the pool of numbers and mailboxes for the run is separate and marked accordingly; staging has a cap on the number of operations, so a mistake does not multiply into hundreds of requests before anyone notices; and the run's logs are available immediately, not only after a manual request.
Frequently Asked Questions
What is the fastest way to check that staging is not pointed at production?
Make one deliberately noticeable test call — create a resource with a unique name — and check whether it shows up in the live account. If it does, the configuration is mixed up.
Can live numbers be used for a short run?
No: even a short run ties up a resource from the live pool, and if cleanup fails, the resource does not return to sale on time.
What if live accounts have already been created by an automated run?
Pull them by an identifying trait — a name prefix or a creation date outside normal traffic — and remove or deactivate them manually, then fix the cause: a shared key or a shared API address.
If tests need a dedicated pool of real numbers and mailboxes without touching live data, the number and mailbox rental section issues resources one at a time and does not overlap with other setups by default.