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.
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.
Automation rulesLive
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
ActiveR2High risk on store sites
ActiveR3Any check failure
ActiveR4Black Friday freeze
Scheduled The problem
Most automated website maintenance is decision-free
Look honestly at a month of maintenance and most of it required no judgement 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. The judgement 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
Actions that cover the workflow
Apply, stage, hold for approval, roll back, pin a version, take a backup, open a ticket, notify a channel, escalate to a person, or run a webhook into your own systems.
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.
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 behaviour 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 for anything not built in
- 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 behaviour.
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.