The tech check before the high season: 14 points you should check off now

A technical check before the peak season isn't maintenance, it's insurance. It costs one day in August and prevents an all-nighter in November. These 14 points are where we most frequently find problems in practice—sorted into foundation, safety, operation, and shop logic, each with the specific steps involved.

The post about the Q4 schedule focused on the " when" : which month is for what, and why November is only good for selling. Today, we're talking about the " what ." Because "checking technology" is one of those phrases that everyone nods at, but nobody knows where to begin.

That's why I didn't write a general list, but rather the one we work through ourselves. Fourteen points, in four sections. Some take ten minutes, two take half a day. And three of them have been skipped ever since I've been in this business—they come last because they're the most expensive.

Why August of all months?

Because you're still allowed to make mistakes now. An update that goes wrong in August costs you an afternoon. The same update on November 20th costs you the day your customers wanted to buy.

Then there's the less pleasant half of the truth: The peak season is also peak season for the other side. The digital association Bitkom surveyed over 1.000 companies for its study— 87 percent reported data theft, espionage, or sabotage, with total damages amounting to €289,2 billion , of which around €202 billion was due to cyberattacks. 34 percent were affected by ransomware . These figures are available in Bitkom's analysis of economic security in the German economy.

There's no need to panic. It's simply a matter of order: first test, then optimize. A fast online store that's encrypted on the second Sunday of Advent helps no one.

Block 1: The Foundation (Points 1 to 4)

1. Shop core and extensions up to date

It sounds trivial, but it's the most common issue. Not because operators are lazy, but because updating during a live operation is frightening—and this fear grows with every month it's postponed. Jumping back from three versions to the current one is a project. Jumping from one is a piece of cake.

Helpful tip: List all extensions with their installed and available versions. Anything more than two minor versions old goes on the list. Anything that hasn't received an update in over a year goes on a second list—called "Find replacements."

2. Check the PHP version — specifically the one that is actually running.

E-Commerce News - Tips & Tricks Christmas business 2026: Why your Q4 will be decided in August

Not the one included in your hosting package. The one your shop actually runs on. It's worth distinguishing between the two, because many servers have one PHP version for the web interface and another for cron jobs. If your import runs at night with PHP 7.4 while the shop uses 8.3, you'll only find out when inventory synchronization throws errors.

An obsolete PHP version no longer receives security updates. This is a theoretical risk in the summer and a practical one in December.

3. Clean up the database

Shops collect data. Orphaned sessions, expired shopping carts, log entries from 2019, indices that were never rebuilt. This costs milliseconds under normal operation and seconds under load.

Look at the three largest tables and ask yourself for each one: Do I still need this data? For log tables, the answer is almost always no. Important: back up first, then delete—not the other way around.

4. Backup — and then actually restore it once

The point nobody likes to talk about because it's uncomfortably specific: A backup that's never restored isn't a backup at all. It's a file created with good intentions.

Check three things: Does the backup run automatically? Is a copy stored off -site? And can a functioning shop be created from this backup in a test environment ? The German Federal Office for Information Security (BSI) has summarized the requirements for a robust backup concept in module CON.3 Data Backup Concept of the IT Baseline Protection Compendium — including the requirement to regularly practice restores.

Block 2: Security (Points 5 to 8)

5. Inventory access points

Who has admin rights in your shop? Count the accounts. If you get a number that surprises you, that's the answer. The intern from summer 2023, the agency you no longer work with, the developer whose access remained "just in case."

Deactivate anything you don't actively need. For everything that remains: two-factor authentication. Yes, even for yourself. Especially for yourself.

6. Patch Management: Who decides what gets rolled out and when?

This isn't a tool, it's a responsibility. In many shops, it simply doesn't exist—updates are installed when someone has time. This works until a critical vulnerability is discovered and nobody knows who needs to take action.

Define two things: Who reviews new security advisories, and how quickly must a critical patch be implemented? The BSI module OPS.1.1.3 on patch and change management serves as a guideline , as it describes precisely these roles and deadlines—and requires a fallback option in case a patch causes a problem.

7. Certificates and their expiry dates

A reader told me last year about a payment service provider whose certificate expired on December 23rd. This isn't an isolated case, but rather a pattern: certificates expire when no one is looking.

Note the expiration dates of your SSL certificate, API keys, payment provider logins, and shipping carrier tokens. Renew anything expiring between November 15th and January 15th now. Not later.

8. A malware scan you didn't write yourself

E-news for ambitious developers - read up to speed Load testing in practice: How to find the limit before the customer does.

Check the file set against the original files of the respective version. Anything that differs and is not yours should be examined. The upload directory is a particularly popular target for attackers because it has write permissions.

One side effect that many underestimate: Upload folders surprisingly often contain old backup copies with extensions like... .bak or .oldThese are delivered by the web server as plain text — including database access data. Search for them. You'll find them.

Block 3: Operation (Points 9 to 11)

9. A staging system that lives up to its name

It's not "we just set something up," but a current copy with the same PHP and database versions as the live system. Anything else is testing something that doesn't exist.

If you have to test a change directly in the live system in November because the staging environment is outdated, you missed something in August.

10. Monitoring with alarms — not just with diagrams

A dashboard that nobody looks at is just decoration. At a minimum, you need: a availability check every few minutes, an alert for server errors, and a notification if the response time exceeds a threshold.

And then there's the part that almost everyone forgets: The alarm has to reach someone who can actually react. An email to an inbox that nobody opens on Sundays is not monitoring.

11. Log rotation and storage space

A full file system will cripple any online store, displaying error messages that point to entirely different causes. Check your free disk space and whether log files are being automatically rotated and deleted. If your log directory is several gigabytes in size, you have your answer.

Block 4: Shop Logic (Points 12 to 14)

12. Consider inventory synchronization under load

As long as you're getting twenty orders a day, an hourly reconciliation won't be noticed. But at three hundred, it will: then you'll reliably sell things that are no longer available and spend December dealing with cancellations and apologies.

Check how frequently your shop and inventory management system synchronize stock levels—and what happens if the interface fails for two hours. We have described in more detail elsewhere what a reliable ERP and inventory management system connection looks like.

13. Play through all the payment methods once.

Not just the ones you use yourself. All of them. Including cancellations mid-payment, including the back button, including guest checkouts. The classic scenario: The customer abandons the purchase, clicks back, and the shopping cart is empty. This order will never come again.

14. Measure charging time under realistic load

The most important point to remember: idle speed says nothing about performance under load. A shop that loads in 1,2 seconds in the morning might take eight seconds at 20 PM on Black Friday. We've broken down which metrics really matter in our article on Core Web Vitals: INP, LCP, and CLS.

The three points that are most often skipped

Now for the honest part. Of these fourteen points, in practice almost always the same three are overlooked — and these are precisely the ones whose absence is the most costly.

E-news for ambitious developers - read up to speed How to tell if your shop is GDPR compliant 📜

The replay test (point 4). Because it takes time and because the result could be unpleasant. That's precisely why you should do it. A backup whose function you don't understand is a gamble.

The access inventory (point 5). Because it feels like bureaucracy. Until an old access point is used for something you didn't intend. And that's exactly what professional attackers are looking for: access points that no one is monitoring anymore.

The alarm pathway (point 10). Because setting up monitoring is fun, but clarifying responsibilities isn't. Nevertheless, this very point determines whether an outage lasts twelve minutes or six hours.

What you can accomplish in one hour

If the list is too long for you, here's the short version for a single afternoon. These four steps cover most of the risk.

First: Count your admin accounts and deactivate anything that isn't actively needed. Second: Note all certificate and key expiration dates and renew anything due between mid-November and mid-January. Third: Restore a backup in a test environment. Fourth: Place an order in your own shop—as a guest, from a mobile phone, using a mobile network, and with the least popular payment method you offer.

If you have another hour to spare, check the upload directories. If you find a file there with the extension... .bak If you find this, you've just closed a data leak you didn't know about. The BSI provides a practical step-by-step guide on how a backup should be structured in its [document/document/etc.]. Instructions “Step-by-step guide to data backup” ready.

Conclusion: The check is the most cost-effective measure of the year

Of all the things you can do before the peak season, this check has the best cost-benefit ratio. It costs no advertising budget, no agency fees, and no new software—just a focused day and the willingness to face some uncomfortable answers.

The hardest part isn't the technique. It's the discipline to do something in August whose benefits only become apparent in December—namely, when nothing happens. Successful preparation feels boring. That's not a flaw; that's the goal.

What's missing from this list?

Fourteen points are my selection, not the gospel. Which point would you add? And even more interesting: Which one have you skipped and later regretted?

Write it in the comments. The best additions to this text so far have always come from people who experienced something that isn't in any manual—expired certificates on a holiday, a cron job with the wrong PHP version, a log directory that filled up the hard drive. Stories like these are worth more than any checklist.

If you want to know where your shop stands technically without having to search yourself: Our free visibility and technical check analyzes every website without registration. And if you'd prefer to go through the points together, you can reach us via the contact page — in August, when it's much quieter than in December.

This post is part of our Q4 series. Every Tuesday, a new post will be published here to help you prepare for the peak season. Next Tuesday: Hosting under Last.js — what your shop really needs in November.