Guides - Hyvä

Magento Maintenance: Three Tests You Can Run Before Monday

- Alexandru-Manuel Carabus

You do not need another generic Magento maintenance checklist. You need to know if your store is bleeding today. Three concrete tests you can run from a browser or SSH in 30 minutes, plus the Vitacom rescue: TTFB from 15,814ms to 12ms, PageSpeed from 12 to 100.

Side view of a small sailing boat gliding on a calm dawn sea, with a tangle of ropes, chains and old anchors submerged directly beneath it, half-buried in silt on the seabed.

In our onboarding experience, most Magento stores we take over ship with at least one missing security patch. Many have a TTFB above three seconds. A meaningful share have a cron that has not run properly in months. This is not "room for improvement". This is stores leaking money while you read this line.

Most articles on Magento maintenance recite the same list: apply patches, clean the database, monitor everything. Correct and useless at the same time. None of it answers the one question that matters to a merchant: does my store need maintenance right now, or can I wait three months?

This post answers that. Three concrete tests, thirty minutes total, browser or SSH. By the end of Friday you know exactly where you stand and what to do next.

Test 1: TTFB (is your server responding like a human)

TTFB (Time To First Byte) is the first signal that your engine is healthy or stuck. A merchant with no infrastructure background feels the slowness as unexplained bounce sessions in Analytics and a vague sense that "the store is heavy today".

How to measure it:

What the numbers mean:

For a cleaner reading, run webpagetest.org three times a day (morning, noon, evening). Averages matter more than a single snapshot, because Magento can look fine at 4am and collapse at 11am when cron and shopper traffic collide.

When we took over Vitacom, TTFB was 15,814ms. Almost thirteen seconds on the server alone, before the browser started rendering anything. After a full Hyvä refactor and DevOps overhaul, TTFB dropped to 12ms. Real number, verifiable in the Vitacom case study.

Test 2: Security patch level

Adobe ships Magento security patches every quarter. There are stores in production today running 2.4.4, out of support since 2023. Every published patch is also a published attack vector: the CVE lists spell out exactly what each patch fixes, so the moment a patch ships, every unpatched store becomes a documented target. Your Magento install is discoverable through public tools like BuiltWith and Wappalyzer, so an attacker does not need to guess which stores run Magento. If yours is unpatched, automated attacks are not a hypothesis. They are statistics.

How to check:

  1. Log in to Magento admin as an administrator.
  2. Open any page in the backend. The Magento version is printed in the bottom-right corner of the footer.
  3. If you have SSH access, `bin/magento --version` from the Magento root gives the same answer.
  4. Compare against the official Magento release notes

What you are looking for:

A free bonus: run `bin/magento setup:db:status`. If it prints "Some modules are out of date" or schema drift warnings, you have your next hint about what a maintenance session should touch.

Test 3: Cron log (where technical debt hides)

Cron does about ninety percent of the invisible work in a Magento store: reindexing, cache cleanup, transactional emails, integrations, invoice PDF generation. If cron stops running the store feels fine for three days, then starts behaving strangely and nobody knows why.

How to check:

Healthy signs:

Alarm signs:

What maintenance actually means

If any of the three tests failed, real maintenance (not the marketing-page version) looks like this:

Prices for this work in the Romanian market range from 500 to 4,000 EUR per month, mostly depending on how honest the agency is about billing. At LIQUIDLAB, Hyvä support and development is billed hourly under a contractual SLA (2h response for critical, 4h for major) and ticketing through ClickUp. It is not a flat monthly fee because we are not a black box. You pay for the real hours worked and see exactly what was done.

The Vitacom rescue

Vitacom.ro came to us with a Magento 2 store on Luma, roughly 180 third-party modules stacked over years, TTFB of 15,814ms and a PageSpeed score of 12. Not a legacy relic. A live store still taking orders every day.

What we did, briefly:

The public, measurable result:

Full details and verifiable metrics are in the Vitacom case study. We do not round the numbers, we do not paraphrase them.

What to do this week

Concrete plan, one test per day:

  1. Tuesday: run Test 1 (TTFB). If it is above one second, flag it as priority.
  2. Wednesday: run Test 2 (Magento version and patch level). If you are below 2.4.6, you have an open security problem, not a scheduling question.
  3. Thursday: run Test 3 (cron log). Five minutes on SSH tells you if cron is running or has silently died.
  4. Friday: put the three results in one document (Google Doc, Notion, a Slack message to yourself). Three problems? That is enough for a real conversation with a technical partner.

If by Friday you have findings you cannot interpret, the most direct next step is our deep code and server analysis: 999 EUR one-time, with 30 days of support included. You get a written report with findings, prioritisation (Critical, Major, Minor) and a concrete remediation plan. No time inflation, no monthly contract required. You see what you have, then you decide what to fix and by whom.

Talk to a senior Magento developer

If you want to walk through your test results with a senior Magento developer before you spend a euro on remediation, book a free strategy call. Thirty minutes, no sales pressure, no automated follow-up sequence. You bring the questions, you leave with a clear direction on what comes next.