Infrastructure

DevOps and monitoring for online stores

Deployments, backups, logs, background jobs and the checks that page you first.

7 guides7 in-depth107 min of reading

Running a store in production is mostly about the database. Code can be redeployed in seconds, but orders, customers and subscriptions change every minute and can't be recreated. That rules out practices that are harmless on a brochure site. A staging push that copies the database replaces every order placed since staging was made. Restoring last night's backup to undo a bad deploy deletes today's orders. A background queue that quietly stops leaves renewals, emails and stock updates undone, and nobody notices until a customer complains. The guides in this topic are built around one rule: deploy files, protect data, and monitor the jobs that nothing inside WordPress can report on.

Zero-downtime WooCommerce deployments copies only your own plugin and theme folders to staging, validates them with smoke tests that run a real add-to-cart through the Store API, and promotes with a files-only push. A failed release is rolled back by redeploying the previous commit, not by restoring the backup. Monitoring Action Scheduler and WP-Cron moves both queues to the system cron and pings an external monitor with the exit code. In our tests on WooCommerce 11.2.1, a recurring job stopped rescheduling after its fifth failure in a row, and a WP-Cron event that hit a fatal error was gone for good. restic backups to IDrive e2 or S3 streams the database dump so a failed dump never becomes a snapshot, verifies part of the repository every night, and runs a monthly restore drill. It also shows how egress pricing decides the bucket bill.

The remaining guides cover visibility. Centralizing PHP, Nginx and WooCommerce logs ships five log sources through Vector, joins stack traces into single events, masks personal data, and kept every event through an outage in our test. UptimeRobot vs custom scripts and StatusCake vs DIY scripts split the work between external checks of what a shopper sees and heartbeats from your own scripts. Railway vs a VPS for webhook relays sizes a receiver that verifies, stores and acknowledges in milliseconds, and shows when per-second billing stops being cheaper than a small server.

Start here

DevOps & monitoring14 min read

Zero-downtime WooCommerce deployments: Kinsta API and GitHub Actions vs manual staging pushes

Let GitHub Actions copy only your own plugin and theme folders to Kinsta staging over SSH. Validate staging through the Kinsta API and with smoke tests: the pages load, a real add-to-cart works through the Store API, and a build marker matches the commit. Then promote with the API's push endpoint set to files only (push_db false, specific folders), after a tagged backup. Never use the default push on a live store: it copies the database too, which replaces every order placed since staging was made. Kinsta says a push has a couple of seconds of downtime at the end, so this is near-zero, not zero. If the live smoke test fails, roll back by redeploying the previous commit, not by restoring the backup, which would take the orders with it.

DevOps & monitoring16 min read

Monitoring WooCommerce Action Scheduler and WP-Cron: Oh Dear vs custom scripts

Turn off WP-Cron's page-load trigger and run both queues from the system cron every minute, with a time limit on each. At the end of every run, ping an Oh Dear scheduled-task monitor with the exit code. That catches the two failures nothing inside WordPress can report: the cron that stopped running, and the run that crashed. Then add an application health endpoint that Oh Dear polls every minute. It reports how far WP-Cron is behind, how many Action Scheduler jobs are past due, jobs stuck in progress, recent failures, and recurring jobs that no longer have a next run. In our tests on WooCommerce 11.2.1, Action Scheduler stopped rescheduling a recurring job after its 5th failure in a row, and a WP-Cron event that hit a fatal error was gone for good. Only the exit code in the ping showed the second one.

DevOps & monitoring16 min read

WooCommerce database and media backups with restic: IDrive e2 vs AWS S3

Back up a WooCommerce store with restic: dump the database with mysqldump through restic's --stdin-from-command, so a failed dump never becomes a snapshot, back up wp-content/uploads, keep 14 daily, 8 weekly and 12 monthly snapshots, read back a different 1/30 of the repository every night, and run a monthly restore drill that loads the dump into a scratch database and compares it with the live store. restic encrypts on your server, so the bucket only ever holds ciphertext. For the bucket, egress decides the bill: IDrive e2 is $6 per TB a month with free downloads up to 3 times the stored volume and no API fees, while AWS S3 Standard is $0.023 per GB plus $0.09 per GB downloaded after the first 100 GB. Below roughly 200 GB, S3 is cheaper; at 500 GB with a monthly full verification read, e2 is $6 against about $47.50.

All devops & monitoring guides

DevOps & monitoring15 min read

Centralizing PHP, Nginx and WooCommerce error logs: Better Stack vs self-hosted Loki

Run one log shipper, Vector, on the store's server. It tails five files: the Nginx access log (written as JSON), the Nginx error log, the PHP error log, the PHP-FPM log and WooCommerce's wc-logs folder. It joins multi-line entries such as a fatal error's stack trace into one event, drops successful static-file requests, masks emails, card numbers and the last part of IP addresses, and sends the events to Better Stack, to a Loki server you run, or to both. A disk buffer and end-to-end acknowledgements kept every event through an outage and a crash in our test. Better Stack is the faster path: 3 GB a month free, then $0.10 to $0.35 per GB, with alerting and on-call built in. Loki costs a second server and your time, but the data and the alert rules stay with you.

DevOps & monitoring13 min read

Monitoring storefront SSL, checkout latency and API health: StatusCake vs DIY scripts

Monitor four things for an online store: certificate expiry on every hostname (and every server behind it), the response time of the cart and checkout pages, the APIs the storefront depends on, and the monitor itself. A cron script in Python can cover the first three from one server, and our tested version alerts Slack only when something changes. What a script on one server can't do is see your store from several regions or confirm a failure from a second location before paging you, and it can't tell you when its own server dies. StatusCake does both: SSL monitors with expiry reminders, uptime checks with confirmation servers, page speed monitors, and a push (heartbeat) test that can watch your cron script. The free plan covers one SSL monitor and 10 uptime checks at 5-minute intervals; Superior is $20.41 a month billed yearly for 50 SSL monitors and 1-minute checks.

DevOps & monitoring16 min read

Hosting e-commerce webhook relays and background workers: Railway vs a self-hosted VPS

Run the webhook receiver as a small always-on service that verifies the signature, writes the event to disk and answers 200 in milliseconds, with a worker forwarding it in the background. Our tested relay used about 31 MB of RAM and 6 ms of CPU per webhook, so on Railway, which bills measured usage per second, it costs well under the $5 that the Hobby plan already includes: $5 a month, deployed from Git. A $5 Vultr or $6 DigitalOcean VPS costs the same and needs you to run Docker, TLS and updates. Railway gets expensive for workers that keep a full vCPU or several GB busy around the clock: a 1 vCPU / 1 GB worker running 24/7 is about $30 a month on Railway against $10 to $12 for a 2 GB VPS. Don't enable Railway's Serverless sleep on a webhook receiver.

DevOps & monitoring17 min read

E-commerce and scraper monitoring: UptimeRobot vs custom scripts for checkout pages, price feeds and cron jobs

Use an external service such as UptimeRobot for anything a shopper would notice: storefront uptime, a keyword monitor that alerts when the Add to cart button disappears, an API monitor that checks the product JSON has a price above zero, and status monitors for payment providers. Use your own scripts for what only you can judge: whether a scraper's output is complete and plausible, and whether the checkout flow works end to end. Connect the two with heartbeat monitors: each script pings UptimeRobot only when it succeeds, so a crashed script, a dead server or a run that produced bad data all raise the same alert. Heartbeat, API and SSL monitors need a paid UptimeRobot plan; Solo starts at $9 a month billed yearly.