Product
Solutions
Compare
Resources
Get early access Talk to us
Automation

Rules that run the routine so you only handle the exceptions

Describe how you want maintenance handled once, and WPCentrify applies it across the portfolio: what updates automatically, what waits for approval, when work runs, who gets told, and what happens when something fails.

Included on every plan. No add-on pricing.

Updated

app.wpcentrify.com/automation
Automation rulesExample data
Active rules
12
3 scoped
Actions 30d
1,842
automated
Escalated
23
needed a human
Time saved
31 hrs
this month
R1Low risk plus security patch
Apply immediately, verify, report
Active1,204 runs
R2High risk on store sites
Stage, screenshot, hold for approval
Active46 runs
R3Any check failure
Roll back, pin version, open ticket, alert
Active9 runs
R4Black Friday freeze
No changes on tagged stores until 2 Dec
ScheduledUpcoming

What is WordPress maintenance automation?

WordPress maintenance automation means letting rules carry out routine work, such as applying updates, taking backups and telling the right person when something fails, so a person only handles the cases that need judgment. Automation is only worth having if every change it makes has a way back and runs only when and where you allow it.

WPCentrify automation rules are written as "when this happens, on these websites, do that". A rule can react to updates waiting, a website going offline or coming back, a security finding, a failed backup or a search visibility problem, and it can apply updates, hold them back, keep a plugin at its current version, take a backup or email somebody. A rule that changes websites refuses to run unless a way back exists first.

WPCentrify automation rules at a glance

  • Triggers: updates waiting, a website offline or back online, a security finding, a failed backup, search visibility switched off or a critical SEO issue.
  • Actions: apply updates, hold updates back, keep a version, take a backup or notify a person.
  • A rule that applies updates will not run unless a way back exists first.
  • Preview what a rule would have done against past activity before you switch it on.
  • Websites are enrolled one by one, and one stop switch pauses every rule in the workspace.
  • Every automated action is recorded in the activity log with the rule that triggered it.
The problem

Most automated website maintenance is decision-free

Look honestly at a month of maintenance and most of it required no judgment at all. A patch release from a well-behaved plugin on a low-risk site was always going to be applied. The backup was always going to run. The report was always going to say roughly the same thing. Each of those still runs through the safe update checks before it is kept. The judgment is concentrated in a small number of genuinely ambiguous cases.

The problem is that the decision-free work is what consumes the time, and it crowds out the cases that actually need thinking about.

What this looks like without a platform

  • Manually approving the same low-risk update thirty times
  • Alert fatigue from notifications that never required action
  • Failures that sit unretried until somebody notices
  • Every site handled identically regardless of what it does
How it works

How rules are built

Conditions from real signals

Risk band, plugin, site tag, client, care plan tier, time of day, whether the site is a store, whether it is currently in a freeze window, and whether previous checks passed.

Actions that cover the workflow

Apply, hold for approval, roll back, pin a version, take a backup, or email the right person.

Scoped and inheritable

Set a rule at portfolio level and override it for one client or one site. A store during its sale week inherits everything except the update policy. The rules act on the same queue you use when you bulk update plugins across multiple sites by hand.

Testable before it runs

Preview what a rule would have done against the last thirty days of activity before you switch it on, so you are not guessing at the blast radius.

In practice

Automation that fails safely

Retry with backoff

Transient failures are retried automatically rather than escalated. Only persistent failures reach a human.

Escalation paths

An unacknowledged critical alert moves to the next person on the rotation instead of sitting unread.

Quiet hours and freeze windows

Nothing runs during a client's peak trading period unless it is a security emergency you have explicitly allowed through.

A record of every automated decision

Each automated action appears in the activity log with the rule that triggered it, so behavior is explainable rather than mysterious.

At scale

Built for a portfolio, not a single site

  • Portfolio, client and site level rules with inheritance
  • Preview a rule against historical activity before enabling it
  • Webhooks into your own systems (planned)
  • Time zone aware scheduling and freeze windows
  • Automatic ticket creation for failures that need a human
  • Every automated action recorded and attributable
Answers

Questions about automation

What people ask before they turn this on.

Start in notify-only mode. Rules evaluate and tell you what they would have done without acting, so you can watch the decisions for a few weeks before enabling anything.

Yes. Rules inherit from portfolio to client to site, and any level can override the one above it. Different care plan tiers commonly get different automation policies.

The most specific scope wins, and the conflict is shown in the interface when you create the rule rather than surfacing later as unexplained behavior.

Yes, if every automated update has a way back and runs inside the hours you allow. In WPCentrify an automation rule that applies updates refuses to run unless a way back exists first, respects each site's maintenance window, and records what it did in the activity log.

A rule can apply pending updates, hold them back, keep a plugin or theme at its current version, take a backup or notify a person. It can be triggered by updates waiting, a website going offline or coming back, a security finding, a failed backup, or a search visibility problem.

Yes. WPCentrify can rehearse a rule against past activity and show what it would have done, before you enroll any website in it. You can also leave a rule in watching mode so it reports its decisions without acting on them.

Press the workspace stop switch. It is the first thing WPCentrify checks before any rule acts, so it overrides every rule on every website until you turn automation back on.

Early access open

Try automation on your own sites

Connect a site in under two minutes and see this working against something real. Free during early access.

Free during early access. Keep your data, export any time.