Observability for Magento and Adobe Commerce means collecting metrics, traces, logs, and real user data so you can answer why the storefront is slow or failing, not just whether it is up. On cloud, New Relic APM ships by default; self-hosted stores assemble their own stack. The paths worth watching are checkout, catalog, cron, and queues.
Most Magento monitoring advice stops at a tool list: install New Relic, add Blackfire, maybe Sentry. That tells you what to buy, not what to watch or how to prove the store is meeting a service level. This guide is for the engineer or architect who owns uptime and answers to a business that measures the storefront in revenue per minute. It covers the stack layer by layer, the paths that lose money when they degrade, how frontend and backend telemetry connect on a Hyva theme, and how to set service level objectives an ecommerce team can defend.
Why observability is different for a Magento store
A Magento or Adobe Commerce store is not a single application. It is PHP-FPM serving requests, a database under heavy read and write load, Varnish or a CDN caching full pages, Redis or Valkey holding cache and sessions, OpenSearch answering catalog queries, a message queue processing asynchronous work, and cron running indexers and scheduled jobs. A slow checkout can originate in any of those, and the symptom (a spinning payment button) looks the same regardless of cause.
Monitoring answers “is it up.” Observability answers “why is it behaving this way,” using data you collected before you knew the question. That distinction matters for Magento because the failure modes are rarely a hard outage. They are a stuck indexer that makes category pages stale, an extension that adds 400ms to add-to-cart, a payment gateway timing out on 2% of orders, or a cron backlog that delays order emails. None trip a simple uptime check, and all cost orders.
The teams that keep a large Magento and Adobe Commerce build healthy treat observability as four connected layers rather than a pile of dashboards. Get the layers right and the tools become interchangeable.
The four layers of a Magento observability stack
Think in terms of what each layer answers, not which vendor sells it. A complete setup covers all four; a gap in any one leaves a class of incident you cannot explain after the fact.
| Layer | What it answers | Primary signal | Common tools |
|---|---|---|---|
| Infrastructure metrics | Is a resource saturated? | CPU, memory, disk I/O, DB connections, queue depth | New Relic Infrastructure, Datadog, Grafana |
| Application performance (APM) | Which transaction and query is slow? | Transaction traces, DB query time, external call latency, Apdex | New Relic APM, Datadog APM, Tideways |
| Logs and errors | What exactly failed, and where? | Exception stack traces, structured application logs | Sentry, New Relic Logs, Datadog Logs, Monolog |
| Real user monitoring (RUM) | What did the shopper actually experience? | Core Web Vitals, page load, JS errors, funnel drop-off | RUMvision, JaJuMa RUM, browser field data |
APM captures server-side execution: PHP, database, and API calls. RUM captures the client side from real browser sessions, including Core Web Vitals. You need both, because a transaction that looks fast in APM can still feel slow to a shopper whose device spends 3 seconds hydrating the page. On-demand profiling with a tool like Blackfire sits alongside APM: APM runs continuously and tells you a route is slow, profiling runs on demand and tells you the exact function call responsible.
What Adobe Commerce Cloud gives you, and its one hard limit
If you run Adobe Commerce on cloud infrastructure, a large part of the APM and logging layer is already provisioned. Per Adobe’s own documentation, every cloud project includes the New Relic service with three components, and the availability differs by plan:
- New Relic APM on all projects (Pro and Starter), for Production and Staging. Transaction tracking, database query analysis, dependency mapping, Apdex scoring, and deployment markers.
- New Relic Infrastructure on Pro projects only, for server-level metrics that connect back to the application data.
- New Relic Log Management on Pro projects only, aggregating application, infrastructure, and network logs into one searchable place.
There is one constraint that surprises teams every time. On Adobe Commerce Cloud you cannot send data from external servers or third-party sources into that managed New Relic account. Monitoring is scoped to the Commerce application environment and the services it calls at runtime. So if your architecture includes an ERP middleware box, a separate search cluster, or a headless frontend hosted elsewhere, those do not appear in the bundled New Relic. You either run a second observability account you control, or you accept a blind spot at exactly the integration boundaries where B2B stores fail most often.
Self-hosted Magento Open Source and self-managed Adobe Commerce have no bundled monitoring at all. That is not a disadvantage: you choose the stack and own the whole picture, including those external systems. The trade is you assemble and pay for it yourself.
Instrumenting the paths that actually lose money
Default APM instrumentation groups Magento requests by controller, which is close to useless for a store because half your traffic lands under a handful of catalog and checkout routes. The work that pays off is defining custom transactions and business-critical alerts on the paths where slowness converts directly into lost orders.
Prioritise instrumentation in this order:
- Checkout and payment. Track payment authorization latency as its own segment, separated from the rest of checkout. A gateway that degrades is invisible if its time is buried inside a broad “checkout” transaction. Alert on payment error rate, not just latency, because a rising decline rate is often a gateway or 3DS problem rather than a code one.
- Add to cart. This fires on nearly every session and is a frequent home for extension bloat. A 300ms regression here taxes the entire funnel.
- Catalog and search. Category and product pages are your highest-volume routes. Watch OpenSearch query time and cache hit rate together; a falling hit rate usually precedes a database that starts to smoke.
- Cron and the message queue. These have no shopper watching, so they fail quietly. Alert on queue depth and on indexer status. A store that “feels slow” for no APM reason is often serving stale data from an invalid indexer or a stuck cron queue.
- The admin. Full page cache never touches the backend, so admin performance is a separate signal. Merchandisers abandoning a slow product grid is a real cost, and it needs its own monitoring and fixes.
For each of these, the useful metric is a percentile, not an average. Average checkout time hides the 5% of shoppers hitting a 6-second payment call. Watch p75 and p95, alert on p95, and you catch degradation while it is still a minority of sessions.
Frontend observability on a Hyva storefront
Server-side APM cannot see what a shopper’s browser does after the HTML arrives. On a Hyva theme, that gap matters, because Hyva’s speed advantage lives in the browser: inline Alpine.js, native JavaScript, and far less client-side work than legacy Luma. To confirm that advantage is holding up in production, you need real user monitoring on the field data, not a one-time Lighthouse score.
The three Core Web Vitals and their “good” thresholds at the 75th percentile, per web.dev, are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. A RUM tool captures these from actual sessions using the browser PerformanceObserver API, along with device, connection, and navigation type. Those last dimensions are what lab tools miss: a cold cache-miss load on a mid-range Android over 4G is a different store than the warm desktop load your team tests on.
Two Hyva-specific things are worth watching. First, INP, because Hyva’s interactivity is Alpine-driven and a heavy third-party script can still block the main thread; if INP creeps up after a marketing tag goes live, RUM shows it before rankings do, and the fix is usually an Alpine pattern or a deferred script. Second, JavaScript error rate by browser, since a single broken Alpine component can silently kill add-to-cart for one browser version while every server metric stays green. Connect RUM funnel data to your APM traces and you can follow a slow session from the shopper’s browser down to the database query that caused it.
Logs and error tracking: from noise to signal
Magento writes a lot of logs, and most of it is noise until an incident makes one line matter. The move that changes this is structured, centralized error tracking. A module such as the community Magento 2 Sentry integration routes PHP exceptions and Monolog output to a dedicated error tracker, where duplicate errors are grouped, tied to a release, and ranked by how many users they hit rather than how many lines they wrote.
The payoff is triage speed. Instead of grepping var/log/exception.log across three web nodes, you see that a specific exception started at 14:20, correlates with your last deploy, and has affected 240 sessions. Session replay, where the error tracker records the browser session leading up to a failure, turns a vague “checkout is broken for some people” ticket into a reproducible bug. For a store that also relies on transactional email, tie your log alerting to delivery too, because a silent SMTP or authentication failure is the kind of thing logs catch and dashboards do not; that is a separate discipline covered in transactional email deliverability.
Keep three log hygiene rules. Log in a structured format (JSON) so fields are queryable. Never log full payment or personal data. And set retention deliberately, because unbounded logs are both a cost and a compliance liability.
SLOs, SLIs, and error budgets for a storefront
An SLA is what you promise a customer or an internal stakeholder. An SLO is the stricter target your team actually holds itself to. An SLI is the metric that measures it. The reason to bother with all three is that they convert “the site should be fast” into a number you can alert on and report against.
The core math is the error budget: the amount of failure an SLO permits in a window. Set the SLO, and the allowed downtime falls out of it.
| Monthly uptime SLO | Allowed downtime / month | Practical read for a storefront |
|---|---|---|
| 99.0% | ~7 hours 18 min | Too loose for a revenue site; a single bad deploy burns weeks of budget |
| 99.9% | ~43 minutes | A common, defensible target for mid-market Magento |
| 99.95% | ~22 minutes | Requires redundancy and disciplined deploys |
| 99.99% | ~4 minutes 20 sec | Enterprise-grade; expensive to guarantee on a single region |
Uptime is the easy SLI. The ones that protect revenue are latency and correctness SLOs on the critical paths: checkout latency under 2 seconds at p95, add-to-cart error rate under 0.1%, catalog page LCP under 2.5 seconds for 75% of sessions. Set the SLO tighter than the SLA so you have room to react, and configure alerts to fire when you have burned part of the budget, not only when you have blown it. A burn-rate alert at 50% of the degradation budget gives your team time to act before shoppers feel it.
Error budgets also settle the recurring fight between shipping features and doing reliability work. If the budget is intact, ship. If you have burned it, the next sprint is stabilization. The number decides, not the loudest voice. This framing is what moves a Magento program from reactive firefighting to a service the business can plan around.
Alerting and on-call without a dedicated SRE team
Most mid-market merchants do not have a 24/7 site reliability team, and they do not need one to run this well. What they need is alert discipline. The failure mode is too many alerts, until the team mutes the channel and misses the one that mattered.
Three rules keep alerting useful. First, page a human only for signals that need a human now: checkout down, payment error rate spiking, database unreachable. Everything else is a ticket, not a page. Second, route through a tool like PagerDuty so escalation is automatic and the right person is reached without anyone watching a dashboard. Third, every alert must be actionable and name the likely path, because “CPU high” at 3 a.m. helps no one, while “checkout p95 over 4s, DB query time doubled” points straight at the fix.
For a lean team, this is often the highest-impact part of the whole stack. You can run excellent instrumentation and still lose an hour of orders because the alert went to an unwatched inbox.
Observability if you are on, or moving to, another platform
The layers translate across platforms even though the tools change. If you also run or are evaluating Shopify and Shopify Plus, you trade the deep server-side APM access of self-hosted Magento for a managed platform where much of the infrastructure layer is Shopify’s responsibility and your observability focus shifts to frontend RUM, app performance, and checkout analytics. On Shopware and BigCommerce, how much of the stack you instrument yourself depends on whether you run headless or on the platform’s own storefront. The constant is the four-layer model; what changes is who owns which layer.
Bemeir’s technology partner ecosystem matters here, because your monitoring is only as complete as your visibility into the payment, search, and fulfillment integrations wired into the store. More on how the team works as an extension of a merchant’s engineering group is on the About Bemeir page.
A 90-day observability rollout
You do not deploy all four layers at once. A phased plan gets value early and avoids alert fatigue.
- Weeks 1 to 3. Confirm APM coverage (New Relic on cloud, or a self-hosted equivalent). Instrument checkout, add-to-cart, and catalog as custom transactions. Establish baselines at p75 and p95. Do not add alerts yet.
- Weeks 4 to 6. Add centralized error tracking and structured logs. Stand up RUM on the storefront and start collecting Core Web Vitals field data. Watch, do not alert.
- Weeks 7 to 9. Define SLOs and error budgets from the baselines you now have. Real numbers beat guessed thresholds.
- Weeks 10 to 12. Turn on alerting with burn-rate rules and route to on-call. Run one game-day: break something in staging and confirm the alert fires, reaches a person, and points at the cause.
By the end you have a store you can explain, a service level you can defend, and the data to decide when reliability work outranks the next feature.
Frequently asked questions
Is New Relic free with Adobe Commerce?
The New Relic service is included with Adobe Commerce on cloud infrastructure. APM is available on all cloud projects for Production and Staging, while New Relic Infrastructure and Log Management are limited to Pro projects. Self-hosted Magento Open Source includes no monitoring, so you provide your own.
Do I need both APM and real user monitoring?
Yes. APM measures server-side execution and cannot see what happens in the shopper’s browser after the HTML is delivered. RUM captures the actual client experience, including Core Web Vitals and JavaScript errors. A transaction that is fast in APM can still feel slow to a real user, and only RUM will show you that.
What uptime SLO is realistic for a Magento store?
99.9% monthly is a common and defensible target for mid-market stores, allowing roughly 43 minutes of downtime a month. Higher targets like 99.95% or 99.99% require redundancy, tighter deploy discipline, and more cost, so match the SLO to what the revenue justifies rather than picking the highest number.
How is observability different on Hyva versus Luma?
The backend layers are identical because Hyva changes the frontend, not the server. The difference is on the client: Hyva’s Alpine.js interactivity makes INP and JavaScript error monitoring more important, since a heavy third-party script or a broken Alpine component shows up in field data before it shows up anywhere else.
Can I monitor my ERP and external integrations through Adobe Commerce Cloud’s New Relic?
No. The managed New Relic account on Adobe Commerce Cloud is scoped to the Commerce application and the services it calls at runtime; you cannot feed external servers into it. To watch an ERP middleware box or an externally hosted headless frontend, run a separate observability account you control.
