Adobe Commerce Monitoring and Observability: Practical Guide

A lot of online stores find out about an outage from a customer on social media: checkout has been rejecting a payment method for an hour, search returns zero results or order confirmation emails stopped going out, while the server dashboards stay green. Tooling is rarely the gap: Adobe Commerce in the cloud ships with New Relic and managed alerts. What breaks down is what gets measured, who receives the alert and what that person does when it fires.

At WolfSellers we implement and run Adobe Commerce (formerly Magento) for brands across North America and Mexico. This article covers day-to-day operations: what your deployment model includes, what to measure, what to alert on without burning out the team and how to respond to an incident. Getting ready for a seasonal peak is covered in our El Buen Fin 2026 guide, Mexico's November sales event. Everything we say about Adobe features comes from Adobe's Experience League documentation, reviewed in October 2026.

---

What monitoring and observability mean for an ecommerce store

Monitoring means watching signals you already know matter —availability, response time, errors, disk space— and alerting when they cross a threshold. Observability is the ability to understand why something you didn't anticipate is happening, using the data the system emits. OpenTelemetry describes it as being able to ask questions about a system from the outside without knowing its inner workings, through three kinds of signals:

Monitoring tells you checkout is slow; observability shows you the slowdown comes from the shipping rate service since yesterday's deployment.

Google's SRE book suggests watching four golden signals —latency, traffic, errors and saturation— and separates symptoms ("checkout is failing") from causes ("the database is saturated"). That distinction decides what wakes someone up at night and what can wait until Monday.

What Adobe Commerce includes to monitor your store

It depends on the deployment model. Adobe describes three: Adobe Commerce on cloud infrastructure (PaaS), Adobe Commerce as a Cloud Service (SaaS) and on-premises installations.

Adobe Commerce on cloud infrastructure (PaaS)

Four details from the documentation that change how you operate:

1. The bundled New Relic is limited. Other New Relic features aren't available, and you can't send data from external servers into that account: your ERP doesn't show up there, only the calls the store makes to it.
2. Don't edit the Managed Alerts policy. Adobe updates it and overwrites your changes. For different thresholds, create your own policy and copy the conditions.
3. Set up a notification workflow (email, Slack, PagerDuty or webhook). The policy already notifies Adobe's teams; without a workflow of your own, your team never hears about it.
4. Fastly logs live in New Relic Logs (Pro): that's where you see cache hits and misses, where traffic comes from and which IPs are crawling your site.

SWAT collects site data on schedules that range from every three hours to once a day, and its permission has to be enabled per role in the Admin (Reports > System Insights).

Adobe Commerce as a Cloud Service (SaaS)

Adobe's comparison page says that in SaaS, platform observability is Adobe managed and the New Relic license is not included. You instrument what you build on top:

• Observability subscriptions (Admin or REST API) that send logs, metrics or traces from webhooks, events and the Admin UI SDK to an OpenTelemetry-compatible endpoint such as Grafana, Splunk or New Relic.
• App Builder and API Mesh, which can send data to your own New Relic account.
• RUM dashboards (Real User Monitoring) for the storefront.

Confirm with Adobe which platform dashboards and alerts you'll see as a customer: the documentation we reviewed doesn't spell it out.

On-premises (or your own cloud)

In its peak-season guide, Adobe flags the bundled New Relic, managed alerts and Apdex review as cloud-only, and SWAT is no longer available on-premises. You or your partner choose and run the whole stack —APM, logs, alerting and on-call. We compare the options in our Adobe Commerce hosting guide.

What to measure in Adobe Commerce, layer by layer

In the most recent versions, Adobe's cloud system requirements list Valkey and no longer list Redis; that's why we say "Redis or Valkey."

Apdex: what it measures and how to read it

Apdex is a 0-to-1 index of satisfaction with response time. New Relic calculates it against a threshold T that you set: up to T a response is satisfied, from T to 4T it's tolerating and counts as half, and above 4T or with a server error it's frustrated. That's why a fast 500 error still lowers Apdex. Per Adobe, 0.5 or lower warrants investigation and below 0.4 is considered an outage.

Two caveats from New Relic: below 100 requests per minute the score is unstable, and you can set a separate T for key transactions such as add to cart or place order.

Real-user experience: CrUX won't catch incidents

According to web.dev, a good experience means LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile, measured separately for mobile and desktop. Search Console and PageSpeed Insights pull that data from the Chrome UX Report (CrUX), which covers the trailing 28 days: useful for trends and SEO, not for learning today that a deployment broke the product page. For that you need RUM.

Cron, queues and indexers: the silent failures

They fail without a single 500 error and get noticed days later:

• Cron. Adobe's list of cron-dependent features includes reindexing, catalog price rules, currency rates and Commerce emails, including order confirmation. If cron stops, the store keeps selling while those tasks don't run.
• Queues. By default, the consumers_runner cron job starts consumers every minute and each one processes up to 10,000 messages. A consumer that doesn't start builds a backlog in exports or inventory.
• Indexers. bin/magento indexer:status shows the pending items for each index. If they grow and don't drain, the prices or stock customers see fall behind.

Business observability: orders, conversion and checkout

This is the layer most stores skip, and the one that catches what infrastructure can't see. Checkout can fail for one bank or one payment method while every server is healthy; the only signal is that fewer orders come in than should.

Compare each signal against its own history for that hour and day of the week, not a fixed threshold. Google's SRE book cites rules that detect unexpected changes in request volume as an example of a simple alert that catches problems very fast.

Synthetic checkout tests

A synthetic test is a bot that walks through the store like a customer, from the outside and every few minutes: home page, search, product page, cart and checkout. It's black-box monitoring: it catches the symptom the way the customer experiences it. To keep it from polluting operations:

1. Use a hidden test SKU, or stop before payment; if you do place orders, use test mode and keep them out of the ERP and away from carriers.
2. Exclude it from analytics so it doesn't inflate traffic or conversion.
3. Run it from more than one location to tell a store failure from a network one.

Since the New Relic bundled with Adobe's cloud is limited to APM, Infrastructure and Logs, you'll need another tool. What to test in a checkout for Mexico is covered in our checkout and payment gateway guides.

SLOs and SLIs for an Adobe Commerce store

An SLI (service level indicator) measures the service from the customer's point of view: out of every 100 attempts to place an order, how many worked. An SLO (service level objective) is the target for that SLI over a time window; OpenTelemetry describes it as the way to tie SLIs to business value.

This table is our recommendation to get started, not a market standard. Calibrate the targets against your own baseline.

Error budget

The error budget is the gap between 100% and the SLO. At 99.9%, it's 0.1%: out of a million requests a month, you can fail a thousand. When the budget runs out, changes pause and the team works on stability; when there's budget left, you ship with more confidence. In Google's example policy, changes account for roughly 70% of its outages, so mark every deployment in New Relic with Track deployments.

Your SLO is not Adobe's SLA. Adobe's comparison lists 99.99% infrastructure and 99.9% application (Managed Services) on PaaS, and 99.9% on SaaS. That covers the platform, not your code, your extensions or your payment gateway integration, which is where many orders get lost.

How to design alerts without alert fatigue

Google's SRE book puts it plainly: paging a person is expensive, and when alerts fire too often people start ignoring them, including the one that mattered. The rules we apply:

1. Only page someone for what's hurting customers right now (orders not coming in, checkout errors). Likely causes, such as a disk at 75%, go to a ticket or a dashboard.
2. Every alert has an owner and a runbook: what it means, how to confirm it, what to do and who to escalate to, like the troubleshooting articles Adobe links to each Managed Alert.
3. Alert on error budget burn, not on every spike. Google's SRE workbook suggests, as a starting point, paging when 2% of the monthly budget burns in one hour or 5% in six hours, and opening a ticket when 10% burns in three days.
4. Review alerts every month: the ones that fired with nobody acting get tuned or deleted.

Severity levels everyone understands

This is the scale we propose; agree on it with the business before your first incident.

Under Adobe's support terms, a P1 is a catastrophic production incident that causes the site to stop operating or accepting orders, or that results in data loss with no workaround. You open the ticket first and then call the P1 line, which handles phone calls in English only.

Incident response and blameless postmortems

Google's SRE workbook sums up incident response as the three Cs: coordinate, communicate and maintain control. For an ecommerce store:

1. Declare. Whoever gets the alert confirms the impact and assigns the severity.
2. Assign roles. An incident commander decides, an operations lead makes the changes and a communications lead keeps the business, customer service and, when relevant, Adobe informed.
3. Mitigate before you diagnose. Roll back the last deployment, disable an extension, switch to the backup gateway or turn off a promotion. Look for the cause while the store is selling.
4. Investigate on a timeline. Observation for Adobe Commerce puts metrics and errors on the same axis; for a low Apdex, Adobe suggests reviewing expensive transactions, non-web jobs, the database and external services.
5. Close and communicate what happened, how long it lasted and what comes next.

The blameless postmortem

A postmortem is the written record of an incident: impact, mitigation, causes and actions to keep it from happening again. Blameless, per Google's SRE book, means focusing on the causes without pointing at people or teams, assuming everyone acted in good faith with the information they had. Where people look for someone to blame, problems get hidden.

Decide ahead of time when one gets written: every Sev1, every Sev2 longer than an hour and any incident that burns a large share of the error budget (Google's example policy sets the bar at 20% of a four-week budget). Our template:

When several postmortems point to the same extension, integration or query, it's no longer an isolated incident: it's technical debt in Adobe Commerce, and it gets measured and paid down as such.

Common Adobe Commerce monitoring mistakes

1. Hearing it from customers first, because there are no business alerts.
2. Watching only infrastructure: green CPU, broken checkout.
3. Editing the Managed Alerts policy, or never setting up the workflow that notifies your team.
4. Alerts with no owner or runbook, which turn into noise.
5. Not marking deployments, and losing track of what changed.
6. Forgetting cron, queues and indexers, which fail without 500 errors.
7. Using CrUX to detect incidents, with its 28-day window.
8. Mistaking Adobe's SLA for your SLO.
9. Postmortems that assign blame or have no actions, which guarantee a repeat.

If incidents repeat every week, more monitoring won't fix it: you need a technical rescue. And if requirement 11.6.1 of PCI DSS 4.0 applies to you, alerts on payment page changes fit into this same scheme.

How we do it at WolfSellers

We start with an assessment: what your deployment model includes, which alerts exist, who receives them and what happened in recent incidents. From there we define with you the critical journeys, their SLIs and SLOs, and the severity levels.

Then we set up our own alert policies alongside Adobe's, workflows, deployment tracking, dashboards by layer, business alerts and synthetic checkout tests, with a runbook for every alert. Each month we review alerts, SLOs and postmortems.

On the Business and Enterprise plans of our support and maintenance service, we handle critical incidents 24/7 from Mexico City on a nearshore model; the Starter plan is 8x5. Our DevOps, Adobe Commerce Cloud and hosting and cloud teams take care of the platform and scaling. If you'd like to review how you monitor your store today, contact us.

---

Frequently asked questions about Adobe Commerce monitoring and observability

What's the difference between monitoring and observability?

Monitoring watches known signals and alerts when they cross a threshold. Observability lets you investigate a problem you didn't anticipate using metrics, logs and traces: the first tells you something is wrong; the second tells you why.

Is New Relic included with Adobe Commerce?

On Adobe Commerce on cloud infrastructure, yes: APM on Pro and Starter, and Infrastructure and Log Management on Pro only, for Production and Staging. On Adobe Commerce as a Cloud Service the New Relic license isn't included, and on-premises you buy your own monitoring.

What are Managed Alerts for Adobe Commerce?

A New Relic alert policy that Adobe maintains for Production: Apdex and error rate on Pro and Starter, plus CPU, memory, disk, MariaDB query load and Redis memory on Pro. You don't edit it; for other thresholds you create your own policy and connect a notification workflow.

What Apdex score is acceptable for Adobe Commerce?

Adobe says 0.5 or lower warrants investigation and below 0.4 is considered an outage. Above that, the target depends on the T threshold you set and on your traffic: below 100 requests per minute the score is unstable.

What is SWAT and who can use it?

The Site-Wide Analysis Tool periodically analyzes your site and provides recommendations, a health index, exceptions and available patches. It opens from the Admin with a role permission and, since April 23, 2024, is no longer available on-premises.

How do I monitor Adobe Commerce as a Cloud Service?

Adobe manages platform observability. You send telemetry from your extensions to an OpenTelemetry-compatible endpoint and use the storefront RUM dashboards.

What is an SLO and how is it different from Adobe's SLA?

An SLO is an internal reliability target for a customer journey, such as placing an order. Adobe's SLA is its commitment on the platform. Your SLO includes your code, extensions and integrations, which the SLA doesn't cover.

When should I open a P1 ticket with Adobe?

When a production incident stops the site from operating or accepting orders, or causes data loss with no workaround, as defined in Adobe's support terms. Open the ticket first, then call the P1 line with the ticket number.

Related services

If this topic is relevant to your business, these services from WolfSellers can help you implement it:

• Adobe Commerce
• eCommerce Marketing
• Adobe Commerce Implementation