A Safety Checklist for Google Ads Scripts That Write
Before a writing script goes live: define what it must never do, run it dry for a week on schedule, cap entities changed and change size per run, honour an exclusion label, and confirm its totals match the interface. Cancelled scripts keep the changes they already made, so there is no rollback.
Everything below applies to scripts that write to the account. A read-only script that is wrong sends a bad email. A writing script that is wrong changes an account you are paid to protect, at an hour when nobody is watching, and the first person to notice is usually the client.
Before you write the script
Ask whether the change needs a script at all. Automated rules cover simple conditions in the interface, with a change history entry and no code to maintain. If a rule can do it, a script is a liability with extra steps.
Define what counts as wrong. Write down, before coding, what the script must never do: never pause more than N campaigns in one run, never change a bid by more than X per cent, never touch anything labelled do-not-automate. These become assertions in the code, not intentions in your head.
Decide who is told. Every write should be visible to someone who did not run the script. An email, a row appended to a Sheet, or a label applied to the modified entity — pick one and make it non-optional.
Before the first real run
- Preview and read the whole log. Not the first ten lines. Preview does not suppress mail or spreadsheet writes, so comment those out for the first pass.
- Run with the dry-run flag on for a full week on schedule. This is the step everyone skips and it is the one that catches the Tuesday case, the end-of-month case, and the campaign that only exists in one account.
- Compare the totals to the interface. If the script reports on spend, its number must match the account for the same window. A gap means something is excluded, usually Performance Max.
- Check the account time zone. Every date boundary in the script depends on it, and it is not necessarily yours.
- Confirm the authorising user. The script runs with the permissions of whoever authorised it. If that person leaves, the script stops.
Limits that belong in the code
| Guard | Why |
|---|---|
| Maximum entities changed per run | A logic error that would have paused four hundred campaigns pauses ten, and you find out from the alert rather than from the client |
| Maximum size of any single change | Caps the damage from a bad calculation. A bid change of 400 per cent is a bug, not a decision |
| Exclusion label | Gives a human a way to protect an entity without editing the script |
| Self-imposed time budget | Stops cleanly rather than being cancelled half applied at thirty minutes |
| Minimum data threshold | Prevents acting on a day with almost no traffic, where every ratio is unstable |
When a script is cancelled at the execution limit, the changes it already made are kept. There is no rollback. A writing script must either be safe to re-run from the start, or must record its own progress so the next run continues rather than repeats.
Running it on client accounts
Tell the client the script exists. Not in an appendix. If an automation can pause a campaign, it belongs in the same conversation as anything else that can pause a campaign.
Label what the script touches. A label applied at the moment of change turns “something changed” into an answerable question three weeks later, when the account history is a wall of automated entries.
Keep a script inventory. One sheet: account, script name, what it writes, schedule, who authorised it, date last reviewed. At eight accounts this is a nicety. At fifteen it is the difference between managing automation and being surprised by it.
Review quarterly. Scripts outlive the situations that justified them. A negative-management script written for a campaign that was restructured last year is now a script with no owner and unexamined write access.
The one-line test
Before you turn off the dry-run flag, answer this: if this script does the worst thing its code permits, at 03:00 on a Sunday, on the largest account, how long until somebody notices and how long to undo it?
If the answer to either half is uncomfortable, the guard rails are missing, not the script.
Questions
- Can I undo the changes a Google Ads script made?
- Not automatically. There is no rollback, and changes made before a script is cancelled are kept. The only practical recovery is a log detailed enough to reverse each change by hand.
- How long should a script run in dry-run mode?
- At least a full week on its real schedule. That is what surfaces weekday-specific behaviour, month boundaries and the accounts that differ from the rest.
- Should I use an automated rule instead of a script?
- If a rule can express the condition, yes. Rules appear in change history, need no maintenance and cannot fail in the ways code does.
- What limits should every writing script have?
- A cap on entities changed per run, a cap on the size of any single change, an exclusion label, a self-imposed time budget below the platform limit, and a minimum data threshold before acting.