Care.Launches 18 Aug 2026

Decide whether to run at all. If there are no updates, or the site is already in maintenance, it exits here and does nothing.

Take a fresh backup labelled for this run. It never modifies a backup that already exists.

Confirm the backup is actually restorable before a single file is touched. If it is not, the run stops here and nothing is updated.

Give every plugin with an update a verdict and put the queue in order. Changes nothing.

The only step that changes anything. One plugin at a time, with a health check after each, and an immediate rollback of that plugin if the site errors.

Compare the key pages before and after to catch layout breakage that returns a 200. Skipped entirely when no screenshot tool is connected.

Once everything has settled, confirm the homepage, checkout and contact form still work end to end. Reports only, because step five already handled rollback.

One short report, then put back everything step one changed and release the run lock.

Every sixty seconds, from more than one region.

Two or three consecutive failures, agreed by at least two regions, before anything is called down.

The moment it is confirmed, not on the next scheduled report.

Keep requesting until it answers again, and record the exact minute.

Start, end, duration and the status code, in a form you can send a client.

Issuer, expiry, chain, and whether the chain is complete.

The registrar record, which expires quietly and takes everything with it.

Most certificates renew at thirty days. One that has not is a renewal job failing silently.

Three warnings, getting louder, rather than one that gets ignored.

Test the renewal endpoint and report the host error verbatim. It changes nothing on the server.

Wherever it lives, with its age and its size.

A truncated archive fails here, which is the whole point of the exercise.

A throwaway copy. The live site is never touched at any point.

Homepage, a product or service page, and the checkout or contact form.

A restore that comes back missing the last three weeks is a different failure, and worth knowing about.

Always, whether it passed or failed. Nothing is left running.

Every registered job, its interval, and when it last actually ran.

Anything past its interval by a margin, not anything late by a minute.

Not "cron is stalled" but "your backups have not run since 14 June".

It reads the schedule. It does not reschedule, delete or trigger anything.

Every plugin with a licence key, and its current status.

From the plugin, and optionally re-checked live against the vendor.

Early enough to raise an invoice, not on the morning it lapses.

Which security updates the site stops receiving. It changes nothing.

Spam and trash, by age, so you can see the shape of it first.

Before a single row moves.

Only rows already marked spam, only past the retention you set. Nothing is hard deleted.

What went, what stayed, and how to get it back.

The error, the log, the last thing that changed, and the exact time it started.

A broken site can still get worse. This is the line that stops that.

The most recent change that fits the error, not the most likely bug in general.

One change, then a health check. Never two changes between two checks.

If the site is worse than when it started, the change goes back immediately and automatically.

Confirm the site works end to end, then record what it was so it is recognised faster next time.

PHP version, database version, memory limit and the web server, as the site itself sees them rather than as the host advertises them.

Every plugin and theme states a minimum PHP version. This names the ones that no longer fit.

PHP versions stop receiving security fixes on a published date. It says which one you are on and when that date arrives.

A host can change the version without asking. It records the version every run, so a change shows up as a change.

It reads the environment. It changes no server configuration, so there is nothing to undo.

Check there is an update, that no other run holds the lock, and that the site answers normally. If any of that fails it exits here and creates nothing.

A patch and a major version are different jobs. It says which this is, and which installed plugins declare they have not been tested against it.

Labelled for this run. Nothing is touched until it finishes.

Through the updater WordPress ships with, holding maintenance mode for the shortest window it can manage.

Core often needs a schema step once the files land. Skipping it leaves the site half updated and the admin nagging forever.

If the site errors or a page stops answering, the previous version and the database go straight back without waiting for you.

Homepage, the admin screen and one front end page per active plugin. Then the maintenance flag comes off.

If there is no theme update, or a child theme is active and its parent is missing, it exits here and changes nothing.

A parent theme edited by hand loses those edits on update. If it finds changed files it stops and shows you which, rather than overwriting somebody's work.

The whole theme folder and the options that carry its settings, before a file moves.

One theme at a time, with a health check after each, and the customiser settings read back afterwards to confirm they survived.

Header, homepage, a post and the footer. A broken layout still returns 200. Skipped entirely when no screenshot tool is connected.

The previous theme files and settings return, and the site looks exactly as it did this morning.

What updated, what rolled back, and the version each theme is on now.

If the site runs in English only, there are no language packs to update and it exits here.

Core, every plugin and every theme with a newer language pack published, and how far behind each one is.

Including any file translated by hand, because those are the ones an update overwrites.

One at a time from the official translation service, never from a mirror.

Any pack that fails to install, or any page that errors afterwards, returns the folder to the snapshot from step three.

Load the homepage and one form in the site language and confirm the strings render rather than falling back to English.

It compares two sites that both run the connector. If only one is connected it says so and exits here.

Core, every plugin and every theme, with the exact version string on each side and the gap named.

Active plugins, the active theme, and the settings that change behaviour rather than appearance.

The newest post, the newest user and the newest order on each side. A staging site six months behind will not reproduce today's fault.

Whether the copy is indexable, whether it can send mail, and whether it still points at the live payment gateway.

It lists the differences in both directions. It copies nothing between the two sites.

Total size, file count, and the largest year folders, so you see the shape of it before anything is decided.

Files on disk with no record in the media library, and library entries no post, page, option or menu refers to. It names which references it could check and which it could not, because page builders hide some of them in serialised data.

Below a threshold you set it reports the number and stops, rather than moving files for a few megabytes.

The exact original path of every file it is about to move, plus the attachment tables. Nothing moves until that record exists.

Everything identified moves into a dated holding folder that is not served to visitors. No file is removed from disk.

Load the pages that most recently used those files and confirm the images still appear.

The holding folder restores every file to the path step four recorded. It is only emptied when you say so, never at the end of the run.

Table sizes, row counts, and which of them belong to a plugin that is no longer installed.

Rows pointing at posts and users that no longer exist, and whole tables left behind by a deleted plugin. They carry very different risk.

No row is deleted before this finishes.

Only metadata whose parent record is genuinely gone, in batches, so a large table does not lock the site while it works.

It names each one, its size and the plugin it came from, then waits. A table you drop does not come back from a report.

The backup from step three restores in one action and is kept for thirty days, rather than being cleared at the end of the run.

In megabytes, with the row count, not as a percentage that sounds better than it is.

Count and size, split into expired, still live, and the ones a plugin left with no expiry at all.

Below a threshold there is nothing to gain and no reason to write to the database, so it reports and stops.

One table, taken fresh for this run.

Rows already past their own expiry timestamp, in batches. A live transient is never touched, so no plugin loses a cache it is still using.

The table from step three goes back in one action if anything on the site starts behaving differently.

Rows removed, megabytes freed, and the plugin that left the most behind, so the cause gets named rather than swept weekly forever.

The total, and the twenty largest with the plugin each belongs to.

Under about 800KB there is nothing here worth the risk of touching. It reports the number and stops.

An option a plugin reads on every request has to stay autoloaded. One read on a single admin screen does not.

Before a single flag is changed.

It sets autoload to no on the ones you approved. No option is deleted and no value is edited.

Every flag it changed is recorded by name, and one action puts all of them back.

Load the homepage, an admin screen and the checkout, and confirm nothing has lost a setting.

Role, the date it was created, and the date it last signed in.

Administrators who only ever publish posts, and editors who have never signed in once.

No sign in for ninety days. A dormant administrator is a password sitting unused where nobody would notice it being used.

Roles a plugin added, and the capabilities inside them that nobody chose deliberately.

It lists the accounts and what each one can do. It removes nobody and changes no role.

The site administration address, and the address on every administrator account.

It resolves, it publishes a mail record, and it is a domain somebody still holds. It does not claim the mailbox is read, because no outside probe can see that.

WordPress holds a new administration address until it is confirmed. One sitting unconfirmed for weeks means the confirmation never reached anybody.

A personal address on a client site, a shared inbox nobody owns, or your own address on all forty sites so that every notice looks like noise.

It reads three settings. It sends no mail and changes no address.

Timezone, date format, time format and the day the week starts on.

The address published on the site, the currency in the store, and the language the content is written in.

A timezone stored as UTC plus one rather than as a city does not follow daylight saving, so it goes wrong twice a year and rights itself twice a year.

Scheduled publishing, order timestamps, report boundaries, and every job that runs at a fixed hour.

It names the setting and the value it should hold. It changes nothing, because only you know where the business actually is.

A post, a page, a category, a date archive and the feed, requested from outside. Each one either answers or it does not.

If all five return a page, there is no fault to fix and it writes nothing.

What WordPress has stored, and whether the server configuration file still carries the block WordPress needs.

The whole file, byte for byte, before a single line is added to it.

Regenerate the rewrite rules, and rewrite only the block WordPress owns. Every other rule in that file is left exactly where it is.

If fewer addresses answer than answered before, the original file returns immediately and automatically.

The same five address types again, plus the two pages with the most traffic behind them.

The WordPress discourage setting, and what the robots file actually serves. If the site is visible it exits here and writes nothing.

A staging copy is supposed to be hidden. It checks this site is marked live before it considers changing anything.

The setting as it stands, so the change is reversible by value rather than by guess.

The setting returns to public and the generated robots file stops telling crawlers to leave.

The value from step three goes back in one action, and the flag returns exactly as it was.

Fetch the robots file and the homepage from our network and confirm neither carries a no-index instruction. Whether a search engine then indexes the site is its decision, not ours.

The address requested, the page that linked to it, and how often. Counts are kept, not visitors.

A scanner probing for a configuration file is not a lost page. Those are counted apart and never reported as a problem.

An address with inbound links or search traffic behind it sits above one nobody has ever asked for twice.

An internal link, an old sitemap entry, a printed campaign, or a page somebody deleted last Tuesday.

It watches and lists. It creates no redirects, because pointing an old address at the wrong page is worse than leaving it dead.

From the redirect plugin, the server configuration file, and anything the SEO plugin manages, so the same address is not being handled twice.

Each rule requested from our network, hop by hop, until it lands or gives up.

Lands in one hop, a chain, a loop, or a redirect to a page that no longer exists. Only the last three are a fault.

If every rule lands in one hop it reports and writes nothing.

In the redirect plugin's own format, before a single rule is edited.

One rule at a time, and only the ones you approved. A loop is broken by removing the second rule, never the first.

One import puts every rule back exactly as it was before the run.

Request each edited rule again and confirm it now lands in one hop with the status code it had.

Total, used and free, as the hosting account sees it rather than as the whole server sees it.

Uploads, backups, logs, cache and the database, each with its own number.

A log file growing by the hour, or a backup plugin quietly keeping every copy it has ever made.

At the rate of the last thirty days, the day it runs out. That date is the part worth acting on.

At eighty per cent and again at ninety, rather than on the morning it fails.

It measures. It deletes nothing, including the backups it has just told you about.

The exact address, the error, and the steps that reproduce it. If it cannot be reproduced there is nothing to isolate, and it says so rather than switching things off hopefully.

The active plugin list, the active theme and their settings are written down before anything is switched. Nothing is switched until that record exists.

The changes apply to a single signed in session through a temporary drop-in file. Visitors keep seeing the site exactly as it is now.

Off in halves, retested after each pass. It reaches the same answer as one at a time and gets there in a fraction of the attempts.

Most conflicts are two plugins, not one. It switches the suspect back on alone to work out which combination actually breaks.

Every plugin returns to the state step two recorded and the temporary file is deleted. This runs whether the isolation finished or not.

The plugin, the combination, the address it breaks, and the version each one was on when it broke.