We automate routine database maintenance — cleaning up post revisions, expired transients, orphaned metadata — running on a schedule after we’re done, which means the same ongoing ownership consideration applies: this needs periodic confirmation it’s still running safely rather than quietly doing something unintended.
Automated database cleanup needs a defined, safe boundary, not a broad ‘clean everything’
We scope exactly what this automation is allowed to touch and how aggressively, since an overly broad cleanup routine can remove something that turns out to matter. That defined scope is documented specifically so it doesn’t drift or get misunderstood as “clean anything that looks unnecessary” if someone else ever needs to modify it later.
Database maintenance automation
Routine database cleanup automated within a carefully defined, documented boundary.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Confirmation of exactly what should be cleaned up and how aggressively (retention periods for revisions, transients, and similar)
- Hosting or database access sufficient to configure the automation
- Confirmation of who should be notified if the automation fails or behaves unexpectedly
This or something else?
| You want routine database cleanup automated on an ongoing schedule | This fix covers it |
| You want a one-time database cleanup done now, not ongoing automation | Database & Data Hygiene category fixes for a one-time pass instead |
| You want backup verification automated, not database cleanup specifically | Automated backup verification script, a different, related kind of automation |
| You’re experiencing a specific performance issue you suspect is database-related | Meta query performance optimization, in the Custom Fields, Post Types & Data Structures category, or a broader diagnostic fix |
What we do
- Confirm the exact scope and retention rules for the cleanup
- Build the automation within that carefully defined, agreed scope
- Configure failure notification where feasible
- Test the automation’s first scheduled run to confirm safe, expected behaviour
- Verify nothing outside the defined scope was affected
- Provide written documentation covering exactly what it does and doesn’t touch
What is included
- Database cleanup automation built to a carefully defined, agreed scope
- Failure notification configured where feasible
- Verified safe first run confirming nothing outside scope was affected
- Written documentation of exactly what the automation does
Not included
- Ongoing, indefinite monitoring of continued safe operation by us — that responsibility transfers to you
- Expanding the automation’s scope later without a documented, deliberate update to what it’s allowed to touch
- One-time database cleanup, a separate, related fix if that’s genuinely all you need
- Recovering data removed by the automation operating exactly within its documented, agreed scope
Questions about this fix
Could this accidentally delete something I actually needed?
We deliberately scope the automation to a carefully defined, agreed boundary rather than a broad 'clean anything unnecessary' approach, specifically to avoid this — anything genuinely ambiguous is left out of scope rather than guessed at.
What happens if I later want it to clean up something else too?
That would be a deliberate, documented update to the automation's scope, not something it should ever expand into on its own — worth treating any scope change as its own small, considered fix rather than assuming it adapts automatically.
How do I know it's still running safely months from now?
We document exactly what it does and how to check its recent activity, and periodically confirming that against what you'd expect is the ongoing responsibility that comes with any persistent automation like this.
Is this safer than just running a one-time cleanup instead?
Ongoing automation prevents the same clutter from re-accumulating, though it does carry the ongoing responsibility of confirming it keeps behaving as intended — a one-time cleanup avoids that ongoing consideration but needs repeating manually over time instead.
Will this run during times that could affect site performance for visitors?
We'd schedule it for lower-traffic periods where possible, since even a well-scoped cleanup operation involves some database activity worth timing sensibly.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.