The work the shop does on its own in the background, how to tell whether the shop, the dashboard and the POS are up, and what to do when something goes wrong.
What runs in the background
Needs the permission Manage store settings.
A lot of the shop’s work happens without anybody pressing a button: emails are sent, stock held in baskets is released, reports are brought up to date. A program on the server called the background worker does all of it, each task on its own timer. Scheduled work, under System in the menu, shows whether it is all happening. It needs the Manage store settings permission.
The tasks are listed by their internal names. The ones you are most likely to care about:
- inventory.expire_reservations — gives back stock held by baskets and checkouts that were never finished.
- orders.abandoned_card_payments — cancels card orders nobody finished paying for, and puts their stock back on sale. Cash on delivery is never touched. An order taken by staff with a payment link waits as long as a draft lasts (Settings → Orders) before it is cancelled.
- orders.expire_drafts — puts away draft orders nobody placed, once they are older than Settings → Orders allows.
- cart.abandoned — sends abandoned basket reminders, if they are switched on. cart.cleanup deletes old baskets nobody came back to.
- reporting.rebuild_rollups, reporting.monthly_customers and customers.refresh_totals — keep the reports and each customer’s totals up to date.
- inventory.snapshot — writes down what is on the shelf once a day, which the out-of-stock part of the products report is built from.
- inventory.low_stock_digest, inventory.back_in_stock and push.low_stock — the low-stock summary, back-in-stock emails to customers on the waiting list, and low-stock notifications to staff phones.
- marketing.scheduled_campaigns — sends campaigns at the time they were scheduled for.
- content.publish_due and catalogue.publish_due — put live the pages and products scheduled for a time that has now passed.
- collection.chase — reminds customers whose click-and-collect order is waiting, and tells them when the hold runs out. It never cancels or refunds anything.
- reviews.invitations — asks recent customers for a review, a few at a time.
- exports.scheduled and exports.expire — send scheduled exports, and delete export files once their links have expired.
- media.backup — copies the day’s uploaded photographs to a backup, where the server has one set up.
- money.exchange_rates — fetches the European Central Bank’s daily exchange rates, for a shop not kept in euros or selling in other currencies.
- payments.settlements — reads back from the payment provider what each card payment and refund came to in your account, with its fee and exchange rate, for the finance report.
- privacy.purge, chat.prune, auth.prune_sessions, outbox.prune and similar — delete old personal data, chats, sign-in records and sent messages once they are past their keeping time.
- monitor.uptime, monitor.watch, monitor.certificates and monitor.prune — the health checks and alert emails described below.
Emails and other messages are not on the timer list. They go out through a queue as soon as they are ready, and only show here if they fail for good — see “Messages that gave up” below.
Read the schedule and recent runs
Needs the permission Manage store settings.
The line under the Scheduled work heading sums it up: either everything is running and nothing has been abandoned, or how many messages have given up and how many tasks are not running as they should.
The schedule lists every task, worst first, with how often it runs, when it last ran and how long it took. Each has a status:
- Failing — its last run failed. A red line says how many times in a row, and the error. Backing off means it is waiting longer between attempts, and says when it will try next.
- Overdue — it has not succeeded for more than twice its usual interval. Usually the worker has stopped.
- Never run — it has not run yet. If the worker is running, it will on its next pass.
- Running — it is running now.
- Healthy — it is running on time.
Recent runs shows the last 40 runs of any task, newest first, marked ok, failed or running, with how long each took and what it did (such as how many items it handled, or why it had nothing to do). If nothing is listed at all, the worker has never started or cannot reach the database — tell whoever looks after your server.
Tip: If a task keeps failing, the people with the Monitor the system permission are emailed after three failures in a row, and again when it works.
Retry or clear messages that gave up
Needs the permission Manage store settings.
When an email or other message fails several times, the shop stops trying and puts it in Messages that gave up, at the top of Scheduled work. Each shows what it was (for example Order confirmation, Password reset link or Abandoned basket reminder), who or what it was for, how many attempts were made, when, and the last error.
- Somebody is waiting — a customer or member of staff never received something they were meant to.
- Internal — nobody is waiting, but something did not happen, such as a sale not reaching your analytics or a report not being rebuilt.
- Read the errors and fix the cause first — for example, an email server that was down or settings that were wrong on Email delivery.
- Tick the messages you want to act on, or tick none to act on all of them.
- Choose Retry (or Retry all) to put them back in the queue. The worker sends them on its next pass.
- Or choose Mark … dealt with (or Mark all dealt with) to take them off the list without sending.
Take care: Retrying into the same fault just uses up the attempts again. And a message marked dealt with is never sent — the record is kept so you can find out later what a customer was not told, but they will not get it.
Check whether the shop is up
Needs the permission Monitor the system.
Health, under System, shows whether each part of the shop is answering. Every two minutes the server checks each one. It needs the Monitor the system permission. The line under the heading says whether everything answered its last check, or names what is not answering properly.
The apps lists what is checked:
- The shop — the website your customers use.
- The dashboard — this back office.
- The POS — the POS.
- The API — the part the website and POS talk to. Its check also asks the database, so a database problem shows here.
- The shop, from the internet — the website at its public address, which also catches a problem with the security certificate or the web server in front of it.
Each is marked Up, Degraded (it answered, but with an error), Down (no answer at all) or Not checked, with when it was last checked. Underneath are Uptime, 24 h and Uptime, 7 days — the share of checks it passed — and Typical answer and Slowest 5%, how long it took to answer. If its last check failed, the problem is shown in red.
Email sending is not checked here. If emails are failing, they show on Scheduled work under Messages that gave up.
Tip: Choose Check now to run the checks straight away instead of waiting up to two minutes.
Outages, incidents and warnings on the Health screen
Needs the permission Monitor the system.
A single failed check is treated as a blip. When the same part fails two checks in a row, an incident is opened and everybody with Monitor the system is emailed. When it answers again, the incident closes and a second email says it is back and for how long it was down.
- Wrong right now — open incidents, with when they started and how long they have lasted so far.
- Recent incidents — what went wrong before, when, and for how long.
- Errors — how many errors are open and how many were first seen in the last 24 hours, with Open the error log.
Two warnings can appear at the top:
- The background worker is not running (red) — nothing has been started by the worker for over 20 minutes. While it is stopped, no checks run, no alert emails go out, and none of the work on Scheduled work happens. Ask whoever set up the shop’s server to check the background worker and start it again, straight away.
- Checks run on the live server (blue) — this copy of the shop is not the live one, so the uptime checks and alert emails are switched off. Errors are still recorded. To try the checks on a test copy, ask whoever set it up to switch them on. Check now says the same.
Take care: Everything here is checked from the shop’s own server. If the whole server stops, nothing on it can send the email that says so.
Read the error log
Needs the permission Monitor the system.
Errors, under System, collects every error from the shop, the dashboard, the POS, the API and the background worker. A problem that happened a thousand times is one row with a count, so the list is of problems rather than of every time they happened. The number beside Errors in the menu is how many are open. Personal details are removed before anything is stored.
- Open Errors. It shows open errors seen in the last 7 days, most recently seen first.
- To narrow it, type in Search (a message, page or task name), choose a Status (Open, Resolved, Ignored or Everything), choose Where (Everywhere, or one part of the shop) and choose Seen in (Last 24 hours, Last 7 days, Last 30 days or Last 90 days).
- Choose Apply.
- Choose an error to see the details.
Each row shows where it happened, the message, how many times, and when it was last and first seen. Use the page buttons at the bottom when there are more than fit on one page.
Tip: After a fix has gone live, filter to the errors it fixed and choose Resolve these … at the top to mark every open error in the list as resolved in one go. The button only appears when Status is Open.
Look into an error, and resolve or ignore it
Needs the permission Monitor the system.
An error’s own page shows What happened: its Status (and who last changed it, and when), Where it happened — including whether it was in a customer’s browser or in background work — From (the page or task), and the full Message. Stack trace shows where in the program it happened, for whoever fixes it. Recent occurrences lists the last twenty times it happened, with the page address and any extra details.
Then decide what to do with it:
- Mark resolved — you have dealt with it. If it happens again it reopens on its own, shows Happened again as who changed it, and you are emailed.
- Ignore — it is harmless or expected. It is still counted, but nobody is emailed about it again.
- Reopen — on a resolved or ignored error, puts it back on the open list.
Errors not seen for 90 days are cleared away automatically.
Who gets alert emails, and about what
Needs the permission Monitor the system.
Alerts go by email to every member of staff whose role has the Monitor the system permission. The owner always gets them. Deactivated staff never do. Each email has an Open in the dashboard button. To change who is told, change the roles on Roles.
You are emailed when:
- a part of the shop fails two checks in a row, and again when it is back;
- an error happens for the first time, or a resolved error happens again — at most one email every 15 minutes, listing up to ten errors;
- a background task fails three times in a row, and again when it works;
- the website’s security certificate is less than 14 days from expiring, which means automatic renewal is failing, and again when it is renewed;
- a new version of the software goes live, or is rolled back.
A Deploy rolled back email means a new version failed its checks and the previous one was put back, so the shop is still running as it was. Nothing needs doing in the dashboard — pass the email to whoever set up the shop’s server so they can find out why before it is tried again.
Take care: If nobody has the Monitor the system permission, the alerts are not sent to anybody. Alerts only run on the live shop.
Payment disputes are alerted separately, because they are about money rather than the system. They are emailed to everybody whose role has Refund orders — see Card payments through Stripe.
Health checks and errors are kept for 90 days, the background task history for 30 days, and past incidents for a year.