Monitoreo y observabilidad en Adobe Commerce: guía práctica

Muchas tiendas en línea se enteran de una falla por un cliente en redes sociales: el checkout lleva una hora rechazando un método de pago, la búsqueda devuelve cero resultados o los correos de confirmación dejaron de salir, mientras los tableros de servidores siguen en verde. Casi nunca faltan herramientas: Adobe Commerce en la nube trae New Relic y alertas administradas. Lo que falla es qué se mide, a quién le llega la alerta y qué hace esa persona cuando suena.

En WolfSellers implementamos y operamos Adobe Commerce (antes Magento) para marcas que venden en México. Esta nota es la operación de todos los días: qué trae tu modelo de despliegue, qué medir, qué alertar sin saturar al equipo y cómo responder a un incidente. La preparación de un pico de temporada está en nuestra guía de El Buen Fin 2026. Lo que decimos de funciones de Adobe sale de su documentación en Experience League, revisada en octubre de 2026.

---

Qué es el monitoreo y qué es la observabilidad en un ecommerce

El monitoreo es vigilar señales que ya sabes que importan —disponibilidad, tiempo de respuesta, errores, espacio en disco— y avisar cuando cruzan un umbral. La observabilidad es la capacidad de entender por qué pasa algo que no anticipaste a partir de los datos que emite el sistema. OpenTelemetry la describe como poder hacerle preguntas a un sistema desde fuera sin conocer su funcionamiento interno, con tres tipos de señales:

El monitoreo te dice que el checkout está lento; la observabilidad te deja ver que la lentitud viene del cotizador de envíos desde el despliegue de ayer.

El libro de SRE de Google propone vigilar cuatro señales doradas —latencia, tráfico, errores y saturación— y distingue síntomas ("el checkout falla") de causas ("la base de datos está saturada"). Esa distinción decide qué despierta a alguien de madrugada y qué espera al lunes.

Qué incluye Adobe Commerce para monitorear tu tienda

Depende del modelo de despliegue. Adobe distingue tres: Adobe Commerce on cloud infrastructure (PaaS), Adobe Commerce as a Cloud Service (SaaS) e instalaciones propias (on-premises).

Adobe Commerce on cloud infrastructure (PaaS)

Cuatro detalles de la documentación que cambian la operación:

1. El New Relic incluido es acotado. Otras funciones de New Relic no están disponibles y no puedes enviar a esa cuenta datos de servidores externos: tu ERP no aparece ahí, solo las llamadas que la tienda le hace.
2. No edites la política de Managed Alerts. Adobe la actualiza y sobrescribe los cambios. Para otros umbrales, crea tu propia política y copia las condiciones.
3. Configura un workflow de notificación (correo, Slack, PagerDuty o webhook). La política ya avisa a los equipos de Adobe; sin un workflow tuyo, tu equipo no se entera.
4. Los logs de Fastly están en New Relic Logs (Pro): ahí ves aciertos y fallos de caché, el país de origen del tráfico y las IP que rastrean tu sitio.

SWAT recolecta datos del sitio entre cada tres horas y una vez al día, y su permiso hay que activarlo por rol en el Admin (Reports > System Insights).

Adobe Commerce as a Cloud Service (SaaS)

La comparativa de Adobe dice que en SaaS la observabilidad de la plataforma es administrada por Adobe y que la licencia de New Relic no está incluida. Tú instrumentas lo que construyes encima:

• Suscripciones de observabilidad (Admin o API REST) que mandan logs, métricas o trazas de webhooks, eventos y el Admin UI SDK a un destino compatible con OpenTelemetry, como Grafana, Splunk o New Relic.
• App Builder y API Mesh, que pueden enviar datos a tu propia cuenta de New Relic.
• Tableros de RUM (Real User Monitoring) para el storefront.

Confirma con Adobe qué tableros y alertas de la plataforma verás como cliente: la documentación que revisamos no lo detalla.

Instalación propia (on-premises o en tu nube)

En su guía de temporada alta, Adobe marca como exclusivos de la nube el New Relic incluido, las alertas administradas y la revisión del Apdex, y SWAT ya no está disponible on-premises. El stack completo —APM, logs, alertas y guardias— lo eliges y lo operas tú o tu partner. Lo comparamos en nuestra guía de hosting de Adobe Commerce.

Qué medir en Adobe Commerce, capa por capa

En las versiones más recientes, los requisitos de sistema de la nube de Adobe ya listan Valkey y no Redis; por eso decimos "Redis o Valkey".

Apdex: qué mide y cómo leerlo

El Apdex es un índice de 0 a 1 de satisfacción con el tiempo de respuesta. New Relic lo calcula con un umbral T que tú defines: hasta T la respuesta es satisfactoria, de T a 4T es tolerable y vale la mitad, y arriba de 4T o con error del servidor es frustrante. Por eso un error 500 rápido también baja el Apdex. Para Adobe, 0.5 o menos amerita investigar y menos de 0.4 se considera caída.

Dos matices de New Relic: con menos de 100 solicitudes por minuto el índice es inestable, y puedes fijar un T propio para transacciones clave como agregar al carrito o colocar el pedido.

Experiencia real: CrUX no detecta incidentes

Según web.dev, una buena experiencia es LCP de 2.5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0.1 o menos en el percentil 75, por separado en móvil y escritorio. Search Console y PageSpeed Insights toman esos datos del Chrome UX Report (CrUX), que cubre los 28 días anteriores: sirve para tendencia y SEO, no para saber hoy que un despliegue rompió la ficha de producto. Para eso necesitas RUM.

Cron, colas e índices: las fallas silenciosas

Fallan sin un solo error 500 y se detectan días después:

• Cron. En la lista de Adobe dependen de cron la reindexación, las reglas de precio de catálogo, los tipos de cambio y los correos de Commerce, incluida la confirmación de pedido. Si se detiene, la tienda sigue vendiendo mientras esas tareas no corren.
• Colas. Por defecto, el cron consumers_runner arranca los consumidores cada minuto y cada uno procesa hasta 10,000 mensajes. Un consumidor que no arranca acumula rezago en exportaciones o inventario.
• Índices. bin/magento indexer:status muestra los pendientes de cada índice. Si crecen y no bajan, los precios o existencias que ve el cliente se quedan atrás.

Observabilidad de negocio: pedidos, conversión y checkout

Es la capa que más tiendas omiten y la que detecta lo que la infraestructura no ve. Un checkout puede fallar para un banco o un método de pago con todos los servidores sanos; la única señal es que entran menos pedidos de los que deberían.

Compara cada señal contra su propio histórico por hora y día de la semana, no contra un umbral fijo. El libro de SRE de Google pone como ejemplo de alerta simple y muy rápida las reglas que detectan cambios inesperados en el volumen de solicitudes.

Pruebas sintéticas del checkout

Una prueba sintética es un robot que recorre la tienda como un cliente, desde fuera y cada pocos minutos: inicio, búsqueda, ficha, carrito y checkout. Es monitoreo de caja negra: detecta el síntoma tal como lo vive el cliente. Para que no ensucie la operación:

1. Usa un SKU de prueba oculto, o detén la prueba antes de pagar; si colocas pedidos, que sea en modo de prueba y sin llegar al ERP ni a la paquetería.
2. Exclúyela de la analítica para que no infle tráfico ni conversión.
3. Córrela desde más de una ubicación para distinguir una falla de la tienda de una de la red.

Como el New Relic incluido en la nube de Adobe se limita a APM, Infrastructure y Logs, necesitas otra herramienta. Qué probar en un checkout para México está en nuestras guías de checkout y de pasarelas de pago.

SLOs y SLIs para un ecommerce en Adobe Commerce

Un SLI (service level indicator) mide el servicio desde el punto de vista del cliente: de cada 100 intentos de colocar un pedido, cuántos funcionaron. Un SLO (service level objective) es la meta de ese SLI en una ventana de tiempo; OpenTelemetry lo describe como la forma de ligar los SLI al valor de negocio.

Esta tabla es una recomendación nuestra para arrancar, no un estándar de mercado. Las metas se calibran con tu línea base.

Presupuesto de errores

El presupuesto de errores es lo que queda entre el 100% y el SLO. Con 99.9%, es 0.1%: de un millón de solicitudes al mes, puedes fallar mil. Con el presupuesto agotado se frenan los cambios y se trabaja en estabilidad; si sobra, se despliega con más confianza. En la política de ejemplo de Google, los cambios explican cerca del 70% de sus caídas: marca cada despliegue en New Relic con Track deployments.

Tu SLO no es el SLA de Adobe. La comparativa de Adobe da 99.99% de infraestructura y 99.9% de aplicación (Managed Services) en PaaS, y 99.9% en SaaS. Eso cubre la plataforma, no tu código, tus extensiones ni tu integración con la pasarela, que es donde se pierden muchos pedidos.

Cómo diseñar alertas sin fatiga

El libro de SRE de Google lo resume: interrumpir a una persona es caro, y cuando las alertas suenan de más, la gente empieza a ignorarlas, incluida la que sí importaba. Reglas que aplicamos:

1. Solo despierta a alguien lo que afecta al cliente ahora (pedidos que no entran, checkout con errores). Las causas probables, como un disco al 75%, van a ticket o tablero.
2. Cada alerta tiene dueño y runbook: qué significa, cómo confirmarla, qué hacer y a quién escalar, como los artículos de diagnóstico que Adobe enlaza a cada Managed Alert.
3. Alerta por consumo del presupuesto de errores, no por cada pico. El workbook de SRE de Google sugiere como punto de partida avisar a la guardia si se consume el 2% del presupuesto mensual en una hora o el 5% en seis horas, y abrir ticket si se consume el 10% en tres días.
4. Revisa las alertas cada mes: las que sonaron sin que nadie actuara se ajustan o se borran.

Severidades: una tabla que todos entienden

Esta es la escala que proponemos; acuérdala con negocio antes del primer incidente.

Según los términos de soporte de Adobe, un P1 es un incidente catastrófico en producción que deja al sitio sin operar o sin aceptar pedidos, o que provoca pérdida de datos sin alternativa. Primero abres el ticket y después llamas a la línea de P1, que atiende por teléfono solo en inglés.

Respuesta a incidentes y postmortem sin culpables

El workbook de SRE de Google resume la respuesta a incidentes en tres C: coordinar, comunicar y mantener el control. En un ecommerce:

1. Declarar. Quien recibe la alerta confirma el impacto y asigna la severidad.
2. Asignar roles. Un líder del incidente decide, un responsable de operaciones ejecuta los cambios y un responsable de comunicación informa a negocio, atención a clientes y, si aplica, a Adobe.
3. Mitigar antes que diagnosticar. Regresar el último despliegue, desactivar una extensión, cambiar a la pasarela de respaldo o apagar una promoción. La causa se busca con la tienda vendiendo.
4. Investigar con una línea de tiempo. Observation for Adobe Commerce pone métricas y errores en el mismo eje; para un Apdex bajo, Adobe sugiere revisar transacciones costosas, tareas no web, base de datos y servicios externos.
5. Cerrar y comunicar qué pasó, cuánto duró y qué sigue.

El postmortem sin culpables

Un postmortem es el registro escrito de un incidente: impacto, mitigación, causas y acciones para que no se repita. Sin culpables significa, según el libro de SRE de Google, enfocarse en las causas sin señalar a personas ni equipos, asumiendo que todos actuaron de buena fe con la información que tenían. Donde se buscan culpables, se esconden los problemas.

Define antes cuándo se escribe uno: todo Sev1, todo Sev2 de más de una hora y cualquier incidente que consuma una parte grande del presupuesto de errores (la política de ejemplo de Google pone el corte en 20% del presupuesto de cuatro semanas). Nuestra plantilla:

Si varios postmortems apuntan a la misma extensión, integración o consulta, ya no es un incidente aislado: es deuda técnica en Adobe Commerce, y se mide y se paga como tal.

Errores frecuentes en el monitoreo de Adobe Commerce

1. Enterarse por los clientes, por no tener alertas de negocio.
2. Vigilar solo infraestructura: CPU en verde con el checkout roto.
3. Editar la política de Managed Alerts, o no configurar el workflow que avisa a tu equipo.
4. Alertas sin dueño ni runbook, que se vuelven ruido.
5. No marcar los despliegues y perder la pista de qué cambió.
6. Olvidar cron, colas e índices, que fallan sin errores 500.
7. Usar CrUX para detectar incidentes, con su ventana de 28 días.
8. Confundir el SLA de Adobe con tu SLO.
9. Postmortems con culpables o sin acciones, que garantizan que el incidente se repita.

Si los incidentes se repiten cada semana, monitorear más no basta: hace falta un rescate técnico. Y si te aplica el requisito 11.6.1 de PCI DSS 4.0, las alertas de cambios en la página de pago entran en este mismo esquema.

Cómo lo hacemos en WolfSellers

Empezamos con un diagnóstico: qué incluye tu modelo de despliegue, qué alertas existen, a quién le llegan y qué pasó en los últimos incidentes. Con eso definimos contigo los recorridos críticos, sus SLI y SLO y las severidades.

Después configuramos políticas de alertas propias junto a las de Adobe, workflows, registro de despliegues, tableros por capa, alertas de negocio y pruebas sintéticas del checkout, con un runbook por alerta. Cada mes revisamos alertas, SLOs y postmortems.

En los planes Business y Enterprise de soporte y mantenimiento atendemos incidentes críticos 24/7 desde México, en modelo nearshore; el plan Starter es 8x5. Nuestros equipos de DevOps, Adobe Commerce Cloud y hosting y cloud se encargan de la plataforma y de la escala. Si quieres revisar cómo monitoreas hoy tu tienda, escríbenos.

---

Preguntas frecuentes sobre monitoreo y observabilidad en Adobe Commerce

¿Qué diferencia hay entre monitoreo y observabilidad?

El monitoreo vigila señales conocidas y avisa cuando cruzan un umbral. La observabilidad permite investigar, con métricas, logs y trazas, un problema que no anticipaste: el primero te dice que algo falla; la segunda, por qué.

¿New Relic viene incluido en Adobe Commerce?

En Adobe Commerce on cloud infrastructure, sí: APM en Pro y Starter, e Infrastructure y Log Management solo en Pro, para Producción y Staging. En Adobe Commerce as a Cloud Service la licencia de New Relic no está incluida, y en una instalación propia el monitoreo lo contratas tú.

¿Qué son las Managed Alerts de Adobe Commerce?

Una política de alertas de New Relic que Adobe mantiene para Producción: Apdex y tasa de errores en Pro y Starter, y CPU, memoria, disco, carga de MariaDB y memoria de Redis en Pro. No se edita; para otros umbrales creas tu propia política y le conectas un workflow de notificación.

¿Qué Apdex es aceptable en Adobe Commerce?

Adobe indica que 0.5 o menos amerita investigar y que menos de 0.4 se considera caída. Arriba de eso, la meta depende del umbral T que definas y de tu tráfico: con menos de 100 solicitudes por minuto el índice es inestable.

¿Qué es SWAT y quién puede usarlo?

El Site-Wide Analysis Tool analiza tu sitio de forma periódica y da recomendaciones, un índice de salud, excepciones y parches disponibles. Se abre desde el Admin con un permiso por rol y, desde el 23 de abril de 2024, ya no está disponible on-premises.

¿Cómo monitoreo Adobe Commerce as a Cloud Service?

Adobe administra la observabilidad de la plataforma. Tú envías la telemetría de tus extensiones a un destino compatible con OpenTelemetry y usas los tableros de RUM del storefront.

¿Qué es un SLO y en qué se distingue del SLA de Adobe?

Un SLO es una meta interna de confiabilidad para un recorrido del cliente, como colocar un pedido. El SLA de Adobe es su compromiso sobre la plataforma. Tu SLO incluye tu código, tus extensiones y tus integraciones, que el SLA no cubre.

¿Cuándo abro un ticket P1 con Adobe?

Cuando un incidente en producción deja al sitio sin operar o sin aceptar pedidos, o provoca pérdida de datos sin alternativa, según los términos de soporte de Adobe. Primero abres el ticket y después llamas a la línea de P1 con su número.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo:

• Adobe Commerce
• Implementación Adobe Commerce
• Infraestructura Cloud