This text is about that second cost: what consumes hours in a WooCommerce store, how long typical repairs take, how the update cycle works and how many hours three store profiles need. The numbers are orders of magnitude from our work, not a promise. If your store needs three hours a month and you handle it yourself, that is also a good outcome.
Why a WooCommerce store consumes hours differently than a SaaS store
On a SaaS platform the core update happens without your involvement. Risk sits in marketplace apps, the theme and your own code, the rest is the vendor's problem.
In WooCommerce it is the other way round. The core itself is rarely the trouble. A typical store with a few million dollars in annual revenue runs from a dozen to several dozen active plugins, each on its own release rhythm. Paid ones stop updating when the licence expires, free ones when the author drops the project. That layer, not the core, generates the work: no single calendar, no single vendor, no single place to see what changed.
The second difference is that you also own the layer underneath: server, PHP version, database, cache. In SaaS it does not exist from your point of view. Here it does, and it can cause an outage that looks like a store bug.
Five things that really break WooCommerce stores
Plugin conflict after an update. Symptom: after an overnight update one element stops working, usually pickup point selection, a coupon or invoice delivery. Cause: two plugins modify the same moment of the order process and one changed how it does it. Order of magnitude: from 1 to 4 hours with a copy from before the update to compare against, far more without.
An overloaded database. Symptom: the admin panel grinds, the order list opens in a dozen seconds, the store bogs down under traffic. Cause: a wp_options table bloated with autoloaded entries, leftovers from long removed plugins, and orders stored as posts and metadata instead of HPOS, the dedicated order tables. Order of magnitude: from 3 to 8 hours. HPOS is a separate project, run only after testing the full plugin list, because incompatible plugins are the usual problem there.
Cart and checkout. Symptom: after a theme change or an update a field customers need disappears, or the checkout looks different than yesterday. Cause: WooCommerce has two variants, classic shortcodes and newer blocks, and some plugins support only one, so one mode on the cart page and another on checkout produces errors that are hard to reproduce. Order of magnitude: from 2 to 6 hours to unify both pages, more if a plugin has to go.
Expired licences on paid modules. Symptom: the plugin works but cannot be updated, and the panel shows a message about the key. Cause: the licence expired, or it was bought on the private account of someone who has left. Order of magnitude: from 15 minutes to 2 hours per plugin if access to the purchase account can be recovered, otherwise you buy it again.
Performance with a larger catalogue. Symptom: filtering and search in a category of several thousand products take too long, a price import from the ERP blocks the store. Cause: queries against product metadata, missing indexes, an import run as one long process. Order of magnitude: from 6 to 20 hours, because this is a rebuild, not a repair.
A broader review of typical incidents is in our text on the most common store failures.
Updates: why we do not run them automatically
Updating everything automatically is the cheapest way to make a store stop taking orders overnight, with nobody finding out until morning. Where a dozen plugins touch the purchase process, an update without a test is a bet.
Our procedure: a copy goes to staging, we install the changes there and walk the purchase path with a test payment, checking shipping, the invoice and the order transfer to the warehouse system. Only then does it go to production, with a backup taken immediately before. Critical updates patching vulnerabilities go fast, in a separate cycle, the rest we batch.
In hours from the pool: with a dozen plugins the update cycle alone is roughly 1 to 2 hours a month, with several dozen plugins and an ERP integration usually 3 to 6, because what grows is not the clicking but the number of paths to retest. Add the cases where an update fails the test and someone picks between the older version and a new plugin.
How many hours a month a WooCommerce store really needs
Three profiles we see most often.
Small, stable store. A few hundred products, a dozen plugins, no ERP integration, changes limited to banners, promotions and content fixes. Real consumption: from 5 to 8 hours a month, half of it updates and reviews. Basic at 250 USD with a pool of 10 hours.
Mid sized store in growth. A few thousand products, a warehouse integration, several payment and shipping channels, a new feature or campaign every month. Real consumption: from 15 to 20 hours a month. Advanced at 500 USD with a pool of 20 hours.
Large multichannel store. A large catalogue, B2B pricing, feeds to comparison engines and marketplaces, several environments, constant conversion work. Real consumption: from 30 to 40 hours a month. Premium at 1,000 USD with a pool of 40 hours.
An hour inside the package costs 25 USD, an hour above the pool 40 USD, and the service runs on business days from 8 to 18. The package follows the planned scope of changes, not the size of the company. A store with 3 million USD in annual revenue that changes nothing for a year fits into Basic. A store with 500,000 USD entering a marketplace and rewiring its ERP will burn Advanced to zero. For the wider calculation, with hosting and licences, see our text on how much online store maintenance costs.
What WooCommerce care should include and usually does not
A checklist for your current provider, five questions answerable in one email.
- Who holds the paid plugin licences and whose account they were bought on. The answer "the agency has that" is a bad one, the licences should be yours.
- Whether a staging environment exists and when it was last synchronised with production. An environment from a year ago is not one.
- Whether anyone tracks licence and certificate expiry dates, and who gets the notification.
- Who has access to the server, hosting panel and database, and who only to WordPress. In an outage that difference is decisive.
- Whether backups exist and whether anyone has ever restored the store from them. An untested backup is an assumption, not a safeguard.
In our contracts a restore test is run and recorded once a quarter, because this is where it most often turns out something has not worked for months.
The line between support and SLA, on a WooCommerce example
Technical support is a pool of hours for changes you commission: a new discount rule, an extra field in the order form, plugin updates, a fix in an email template, moving a feed. You report it, we do it, the hours come off the pool, and consumption is visible in Gorilla Panel.
SLA answers the other kind of event: the store or a key function has stopped working and you want to know before the customer does. The store is checked every 60 seconds, a person verifies each alert, and a critical event gets diagnostics and a post incident note. We guarantee response time, not repair time, because the cause can sit with the hosting provider or an external payment gateway, beyond our control. Monitoring starts at 240 USD a month. The difference is covered in our text on technical support versus SLA.
A WooCommerce store needs both for a different reason than a SaaS store: plugin updates are the event after which something most often stops working, so the same cycle produces both planned work and risk someone has to watch.
Taking over a store previously run by someone else
We do not start with changes, we start with the facts. A technical audit: versions, PHP version, state of the database, how orders are stored, the cart and checkout mode, custom code in the child theme. A plugin inventory split into free, paid with a valid licence, paid with an expired one, and abandoned. Access sorted out: server, hosting panel, domain, purchase accounts, repository if one exists.
That is usually from 8 to 16 hours and ends with one list of things to do, split into risks now and what can wait. Only then does a package conversation make sense, because only then is it clear how many hours a month this store consumes.
Compare the support packages and SLA levels on /en/sla-help-desk and pick the one matching your planned changes for the next quarter. To start with data rather than a conversation, enter your store address into Tester eCommerce: you get a free diagnosis of its technical condition, usable with your current provider too.