- Admin API, App Shopify, Shopify Dev Dashboard, Sviluppo Shopify, Webhook
- Francesco Guiducci
Shopify Dev Dashboard 2026: cómo monitorizar API, webhooks y rendimiento de apps
El Dev Dashboard de Shopify se ha convertido en el punto central para entender si una app funciona correctamente antes de que un error se convierta en un problema para el merchant. Con la actualización del 25 de septiembre de 2026, Shopify reunió en el mismo entorno el estado de las apps, alertas, volumen y errores de API, webhooks, Shopify Functions, logs y rendimiento de las páginas integradas en el admin.
La parte útil no es simplemente tener otro dashboard. Es poder pasar de una señal agregada —por ejemplo, un aumento de errores— a los eventos que la han generado, filtrando por tipo, tienda, estado y periodo. Para quien desarrolla o mantiene apps Shopify, esto ayuda a investigar la causa y no solo el síntoma.
Qué muestra hoy el Dev Dashboard
La vista de una app separa tres áreas que conviene no mezclar: Operations para la salud técnica, Admin performance para la experiencia de las páginas de la app dentro del admin del merchant y Growth para datos como instalaciones, desinstalaciones e ingresos cuando el rol del usuario tiene acceso a información financiera.
Para depurar, Operations suele ser el punto de partida más útil. Shopify mide llamadas a la Admin API, entregas de webhooks y ejecuciones de Functions. La tasa de error se muestra junto al volumen, por lo que el mismo porcentaje puede significar algo muy distinto si procede de unas pocas llamadas o de miles de solicitudes.
Cuando una métrica necesita análisis, el enlace a Logs abre la vista ya filtrada por el tipo de evento y por los fallos. Ese paso convierte un gráfico en evidencia concreta.
API: de la tasa de error a la solicitud que falló
En Logs se pueden consultar solicitudes GraphQL y REST con contexto útil para el troubleshooting: estado, target, versión de API y, para GraphQL, coste de la query respecto al rate limit disponible.
Un detalle importante: HTTP 200 no significa automáticamente que una operación GraphQL haya tenido éxito. La documentación de Shopify recomienda abrir el detalle y revisar la respuesta de la operación, porque pueden existir errores GraphQL aunque el transporte HTTP haya sido correcto.
La pestaña API health también muestra el uso de API deprecadas. Su estado considera las llamadas hechas con el token de la app durante los últimos 14 días, lo que ayuda a distinguir una futura tarea de actualización de una llamada deprecada que ya está ocurriendo en el tráfico real.
El informe necesita contexto: herramientas internas que utilicen el token de la app también pueden influir en ese estado. Una llamada deprecada realizada desde Postman, por ejemplo, puede aparecer en el reporte.
Webhooks: qué vigilar antes de que se conviertan en un incidente
Para los webhooks, Shopify muestra volumen, tiempo de respuesta, tasa de fallo y entregas individuales. La documentación diferencia un indicador “High” en el gráfico del alert crítico Webhook failures. Este último usa un criterio más estricto: más del 0,5% de entregas fallidas sobre al menos 500 entregas en 24 horas.
Esa cifra no es un objetivo al que acercarse. Indica cuándo Shopify considera que los fallos son lo bastante consistentes como para poner en riesgo las subscriptions de webhook. Shopify reintenta las entregas fallidas y, si los fallos persisten, puede eliminar la subscription y dejar de entregar ese topic.
Una investigación práctica empieza por la tienda afectada y la hora en la que el merchant notificó el problema, y después revisa las entregas en orden. Así es más fácil distinguir endpoints inaccesibles, códigos de respuesta incorrectos y problemas ligados a una solicitud concreta.
Admin performance no es la velocidad del backend
Admin performance mide tres Core Web Vitals en las páginas de la app dentro del admin: LCP, INP y CLS. Se miden en el navegador del merchant, no en el servidor de la app.
La diferencia es importante. Un backend rápido no compensa una página embedded que tarda en renderizar, reacciona tarde a una interacción o desplaza elementos mientras carga.
Shopify utiliza los mismos Core Web Vitals para Built for Shopify, pero la card del Dev Dashboard y la evaluación de Built for Shopify no son idénticas. Built for Shopify usa su propia ventana de 28 días y exige un número mínimo de mediciones, por lo que la valoración de la card no debe interpretarse como el veredicto final de Built for Shopify.
Los límites de los logs que conviene conocer
Los logs son muy útiles, pero no constituyen un sistema de observabilidad universal. Shopify los conserva durante 30 días y una única ventana de consulta puede abarcar como máximo 7 días. En rangos amplios, la tabla también puede mostrar una muestra en lugar de todos los eventos coincidentes, y la interfaz avisa cuando esto ocurre.
Los request y response body grandes pueden quedar truncados. Algunos detalles de Functions también pueden depender de los scopes disponibles o del acceso a la tienda correspondiente.
El límite más importante es conceptual: Logs registra lo que Shopify puede ver. Una solicitud que el navegador del merchant envía directamente al backend propio de la app no necesariamente pasa por los sistemas que aparecen en el dashboard. Por tanto, una timeline vacía no demuestra que no haya ocurrido nada.
Un flujo de debugging sencillo
- Identificar la tienda y el momento del problema, en lugar de empezar por un gráfico global.
- Revisar los alertas, especialmente deprecaciones, fallos de webhooks y errores de Functions.
- Abrir Operations para entender si el patrón afecta a API, webhooks o Functions.
- Bajar a Logs y leer en orden los eventos filtrados.
- Comprobar lo que Shopify no ve: backend propio, base de datos, colas, servicios externos y actividad client-side cuando sea relevante.
- Cerrar con un readback real, no solo con el hecho de que el error haya desaparecido del código.
El mismo principio sirve cuando se trabaja con Shopify Functions y lógica custom: las métricas y los logs reducen el campo de investigación, pero la verificación final debe hacerse sobre el comportamiento real de la app.
Qué no sustituye el Dev Dashboard
El Dev Dashboard cubre bien la parte que Shopify puede observar directamente. No sustituye automáticamente los logs del backend propio, el monitorizado de la base de datos, los errores de servicios de terceros ni un sistema interno de alertas cuando la app tiene componentes fuera de Shopify.
En una app Shopify pequeña puede eliminar bastante fricción del troubleshooting en la plataforma. En una arquitectura más compleja se convierte en una fuente que debe correlacionarse con el resto de la evidencia técnica.
Por qué también beneficia al merchant
El merchant no necesita utilizar el Dev Dashboard para beneficiarse. El valor está en que quien mantiene la app puede llegar antes a evidencia ligada a una tienda concreta: una entrega de webhook fallida, una llamada API problemática, una Function con error o una regresión de rendimiento dentro del admin.
También es una forma útil de evaluar el método de desarrollo. Una corrección no debería terminar con “el cambio se ha desplegado”. Debería terminar con evidencia de que el comportamiento esperado vuelve a funcionar en el runtime real.
La regla operativa
Usar el Dev Dashboard para reducir el campo del problema, no para declarar automáticamente que el problema está resuelto. Alertas, métricas y logs son evidencia valiosa, pero tienen límites de visibilidad y deben ir seguidos de una verificación real de la función afectada.
Para el desarrollo de apps Shopify, la actualización de septiembre de 2026 hace este recorrido más directo: menos saltos entre paneles separados y una línea más clara entre indicador, log y evento específico.
