Bulk operations in WHM without breaking half the network

Anything you do to every account at once is the most dangerous thing you can do on a hosting network, because the mistake arrives everywhere simultaneously. The technique is not to avoid bulk operations but to make them survivable.

The rule

Never let the first execution of an operation be the one that touches everything. One, then a few, then the rest. This costs an hour and prevents the class of afternoon where thirty sites are wrong at the same time.

1. One account. The least important one you own. Run it, look at the result, use the site.
2. Three or four that differ. One with a shop, one with a form, one plain, one on the pinned PHP version. Differences surface here.
3. The rest, in batches. Not one command over thirty accounts, but several over a few each, with a look in between.

Before you start

• Backups exist and are off the server. Verified, not assumed.
• You can undo it. If the answer is "restore from backup", that is not an undo, it is a recovery. Know the difference before you begin.
• You know how many accounts are in scope. A number, not "all of them". Surprises here are the expensive kind.
• It is not peak traffic. And not the last hour of your working day.

The operations that bite hardest

• Lowering a package limit. Accounts over the new quota are instantly over quota, and the site may stop being able to write anything.
• A network wide PHP change. Sites that were quietly relying on old behaviour break together.
• Purging every cache. Every site rebuilds from cold at once, producing exactly the load spike your limits exist to contain. Covered in Speed and Caching.
• Mass password rotation. Correct in principle, but it breaks every script and integration in the same instant if you have not inventoried them first.
• Bulk termination. There is no undo. Suspend the batch, wait, then terminate.

Stagger, do not serialise into one command

Where an operation causes work rather than just changing a setting, spreading it over time matters as much as the batching. Thirty accounts rebuilding caches, running backups or reindexing at the same minute is one large spike. The same thirty spread over an hour is invisible.

The work is identical either way. Only the concurrency changes, and concurrency is what resource ceilings actually govern, as described in Platform and Limits.

Automate carefully, or not at all

If you script bulk work, two habits are worth more than the script:

• Have a dry run mode that prints what it would touch without touching it. Read the output before removing the flag.
• Use a scoped token, not your password. A script that can only do the one thing it was written for cannot do anything else when it misbehaves. See the token discipline in this section.

Afterwards

Check a sample rather than assuming success. One page per site, loaded as a visitor, is enough to catch the majority of failures. Then wait a day before doing the next bulk thing, because some failures only appear on the next publish, the next cron run or the next renewal.

If something did go wrong across many accounts, stop and tell us what you ran rather than attempting a second bulk operation to fix the first. The second one is usually what turns a bad afternoon into a bad week.

The interface reference is at docs.cpanel.net.