The Adobe Commerce maintenance retainer is the right structure for ongoing operations work. The structure that elevates a maintenance retainer from “keep the lights on” to “actually compounding value” is the quarterly health check. Done well, the quarterly is the artifact that gives the executive sponsor confidence in the agency, surfaces small problems before they become large, and produces a backlog of medium-priority improvements that ship between the major projects.
Done poorly, the quarterly is a 40-page PDF that nobody reads, written in the last 48 hours before the deadline, full of generic recommendations that do not apply to the store. We have seen both. The difference is in the discipline of the audit itself, not in the length of the document.
This piece is the checklist Bemeir’s Adobe Commerce maintenance practice runs on every retainer client every 90 days. It is mechanical on purpose. The point of the discipline is that it does not depend on inspiration. The same checklist produces consistent value every quarter, and the trends across quarters tell the real story.
What the health check is for
The health check is not the same as monitoring. Monitoring tells you what is wrong right now. The health check tells you what is drifting in the wrong direction, what is technically debt accumulating, and what is the agenda for the next 90 days of work.
The audience for the health check is two-layered. The first audience is the engineering team itself, which uses the audit to set the maintenance backlog. The second audience is the executive sponsor, who uses the audit to understand the operational state of the store and to make business decisions about what to invest in.
The artifacts that result are usually three. A short executive summary of two to four pages for the sponsor. A detailed engineering report of 15 to 30 pages for the team. A prioritized backlog of recommendations with estimated effort and expected impact. The three artifacts together take a senior engineer two to four days to produce on a typical mid-market store.
The categories the audit covers
A complete Adobe Commerce health check covers eight categories. Each one has a defined set of questions and a defined set of artifacts that should be produced. The order below is roughly the order we run them in, but the order matters less than the completeness.
The first category is infrastructure. Are the servers healthy? Is capacity right-sized for current and projected traffic? Are backups working? Is monitoring complete?
The second is application performance. Are Core Web Vitals trending in the right direction? Is TTFB stable? Are response times at the percentiles you care about within target?
The third is codebase health. Has the technical debt grown or shrunk this quarter? Are tests passing? Is documentation up to date? Are pull requests being merged in a healthy cadence?
The fourth is security posture. Are patches current? Are dependencies up to date? Are access logs clean? Is the WAF tuned?
The fifth is integration health. Are the third-party services the store depends on stable? Are the data flows in good shape? Are any integrations producing errors quietly?
The sixth is data integrity. Is the catalog data clean? Are customer records consistent? Is the order flow producing the expected events?
The seventh is business performance. Is conversion rate stable? Is AOV stable? Is search effectiveness improving or degrading?
The eighth is the backlog and roadmap review. What did we plan to ship last quarter? Did we ship it? What is on deck for next quarter? Is the priority order still correct?
Infrastructure audit
The infrastructure audit asks five specific questions and produces five specific artifacts.
What is the current capacity utilization at peak and at average? Pull the CPU, memory, and disk utilization data from the last 90 days. Identify any sustained period of high utilization. The artifact is a utilization chart with annotations on any high-utilization periods and the apparent cause.
Is the backup strategy complete and tested? Verify that backups are being taken, retained for the contracted window, and that at least one restore has been performed in the quarter to confirm the backups are actually restorable. The artifact is a backup-and-restore log with timestamps.
Are the secrets in the secrets manager current and rotated according to policy? Audit the encryption keys, API keys, and database credentials. Rotate anything overdue. The artifact is a rotation log.
Is the monitoring stack covering everything it should? Audit the alerts. Confirm each alert has fired at least once in the last 90 days or has a documented reason for being included. Confirm no critical path is unmonitored. The artifact is the alert inventory with status notes.
Is the disaster recovery plan current? Read the DR plan. Confirm the contact lists are correct. Confirm the runbooks reference current systems. The artifact is a DR plan version log with any updates made this quarter.
The AWS Well-Architected Framework is a useful reference for what mature infrastructure hygiene looks like, regardless of where the Adobe Commerce store actually runs. The Magento-specific pieces are about respecting the platform’s caching, queuing, and indexing infrastructure.
Application performance audit
The application performance audit pulls four metrics across the quarter and produces trend charts.
Core Web Vitals at the 75th percentile, broken out by mobile and desktop, by page type. The trend should be flat or improving. Regression in any category warrants investigation.
TTFB at the 50th and 95th percentile, broken out by cache hit and cache miss. The trend should be flat. Increasing TTFB on cache misses usually indicates a database or PHP issue that is worth investigating.
Application response time at the 95th percentile across the top 10 endpoints by traffic. The trend should be flat. Increasing response time on a specific endpoint is the most common indicator of code that has slowly become slow over a series of releases.
Cache hit ratio at the Varnish layer and at the application full-page cache layer. The trend should be flat or improving. Decreasing cache hit ratio usually means a new feature has been added that disables caching for a path that should be cacheable.
The table below is the format the application performance section typically uses.
| Metric | Current quarter median | Prior quarter median | Trend | Notes |
|---|---|---|---|---|
| LCP (PDP mobile P75) | 2.1 s | 2.0 s | Slightly worse | Investigate banner module change |
| TTFB (cache miss P95) | 480 ms | 510 ms | Better | New Redis tuning paid off |
| Checkout submit time P95 | 1.8 s | 1.7 s | Slightly worse | One additional payment gateway call |
| FPC hit ratio | 84% | 86% | Slightly worse | New layered nav filter affecting cache key |
The trends matter more than the absolute numbers. A store with a 2 second LCP that is staying at 2 seconds is healthy. A store with a 1.5 second LCP that is creeping toward 2 seconds is unhealthy and warrants investigation now.
Codebase health audit
The codebase health audit looks at four indicators.
Technical debt, measured as a curated list of known issues with documented effort estimates. The list should shrink or stay flat across quarters. If it is growing, the engineering team is not paying down debt at the rate it is accumulating.
Test pass rate and coverage, measured against the codebase. Pass rate should be near 100 percent. Coverage should be flat or improving.
Pull request cycle time, measured from open to merge. A healthy team has a median cycle time of one to three days. Longer cycle times usually mean either the team is overcommitted or the review culture has degraded.
Documentation freshness, measured as the percentage of documentation pages that have been reviewed in the last six months. Stale documentation accumulates fast and is invisible until somebody needs to use it.
The SonarQube guide to code quality metrics and the DORA metrics are useful reference points for what these numbers should look like in mature engineering organizations.
Security audit
The security audit pulls four checks.
Patch level, compared to the latest available Adobe Commerce release. The store should be no more than one minor version behind, with all security patches applied within 30 days of release.
Dependency hygiene, measured against composer.lock and any third-party JavaScript bundles. Run a dependency vulnerability scan. The number of known CVEs in dependencies should be zero for critical and high severity, and minimal for medium severity.
Access logs, audited for the quarter. Confirm no anomalous admin login activity, no successful exploitation attempts, no unusual API access patterns.
WAF and rate limiting, tuned to current traffic patterns. Confirm the WAF is not blocking legitimate traffic and is catching the obvious malicious traffic.
The OWASP Top 10 and the Magento Security Center are the references. The quarterly security audit should produce a one-page summary of patch status, CVE exposure, and any notable events.
Integration and data integrity audits
The integration audit confirms that every third-party service the store depends on is healthy and that the data flows between systems are correct. Pull error rates from each integration. Confirm any silent failures are being surfaced. Confirm the data mappings between Adobe Commerce and the ERP, CRM, OMS, PIM, and other systems are still correct.
The data integrity audit runs a set of consistency queries against the database. Are there orders without customer records? Customer records without addresses? Products in categories that no longer exist? Inventory levels that match the warehouse system? The queries are not exotic. They are the SQL questions that surface when something has drifted.
The Adobe Commerce data flow documentation is a reasonable starting point for what the canonical flows should look like.
Business performance and roadmap review
The business performance section pulls conversion rate, average order value, and the top funnel drop-off points for the quarter. The numbers tell the story of whether the store is performing the way the business expects. Anomalies surface here, and the maintenance team often spots issues that the business has been quietly compensating for without noticing.
The roadmap review closes the audit. Compare the prior quarter’s planned work to what actually shipped. Identify the gaps, the surprises, and the items that slipped. Use the gap analysis to inform the next quarter’s priorities. Bemeir’s pattern is to publish a one-page “what we promised, what we shipped, what is next” summary as the closing artifact of every quarterly. The discipline of writing this down compounds across quarters and is the single most useful artifact for retaining executive trust.
Why quarterly works
The 90-day cadence is the right interval for several reasons. It is long enough that meaningful trends are visible. It is short enough that issues are caught before they compound. It aligns with the business’s natural quarterly planning rhythm. It produces a body of work, after four quarters, that documents the operational state of the store over a year.
Stores that run the quarterly discipline accumulate a maintenance backlog that the engineering team can actually pay down. Stores that do not run it accumulate technical debt invisibly until something forces a reckoning. The discipline is the difference. The mechanics are not exotic.
If you are evaluating maintenance retainers across Shopify Plus, Shopware, or BigCommerce partners, ask each one whether they include a quarterly health check as a standard deliverable. The agencies that do are usually the ones running mature operations. The agencies that do not are usually the ones that will let your store drift quietly between major projects. The quarterly is the artifact that distinguishes the two, and asking for it is the cheapest diligence available at retainer-evaluation time.
