Il Dev Dashboard di Shopify è diventato il punto centrale per capire se un'app sta funzionando bene prima che un errore si trasformi in un problema per i merchant. Con l'aggiornamento del 25 settembre 2026, Shopify ha portato nello stesso ambiente stato delle app, alert, volumi ed errori API, webhook, Shopify Functions, log e performance delle pagine embedded nell'admin.
La parte interessante non è avere “un'altra dashboard”. È poter passare da un segnale aggregato — per esempio un aumento degli errori — agli eventi che lo hanno prodotto, filtrando per tipo, store, stato e intervallo temporale. Per chi sviluppa o mantiene app Shopify, questo riduce il rischio di diagnosticare un problema guardando solo il sintomo.
Cosa mostra oggi il Dev Dashboard
La vista di una singola app separa tre aree che conviene non confondere: Operations per la salute tecnica, Admin performance per l'esperienza delle pagine dell'app nell'admin merchant e Growth per dati come installazioni, disinstallazioni e ricavi quando il ruolo ha accesso ai dati finanziari.
Per il debugging, la parte più utile è Operations. Shopify misura chiamate Admin API, consegne webhook e run delle Functions. Il tasso di errore viene mostrato insieme al volume: la stessa percentuale può avere un significato molto diverso se deriva da poche chiamate o da migliaia di richieste.
Quando il dato merita un approfondimento, il collegamento ai log apre la vista già filtrata sul tipo di evento e sugli errori. È il passaggio che consente di evitare una lettura puramente statistica e arrivare all'evento concreto.
API: dal tasso di errore alla richiesta che ha fallito
Nei log si possono vedere richieste GraphQL e REST con informazioni utili al troubleshooting, tra cui stato, target, versione API e, per GraphQL, costo della query rispetto al rate limit disponibile.
Un dettaglio importante: HTTP 200 non significa automaticamente che una chiamata GraphQL sia riuscita. La documentazione Shopify ricorda di aprire il dettaglio e verificare la risposta dell'operazione, perché gli errori GraphQL possono essere presenti anche con trasporto HTTP riuscito.
C'è poi la scheda API health, che segnala chiamate a API deprecate. Lo stato considera le chiamate effettuate con il token dell'app negli ultimi 14 giorni. Questo aiuta a distinguere una semplice attività di aggiornamento da una deprecazione che si sta già manifestando nel traffico reale dell'app.
Va però interpretata correttamente: anche strumenti interni che usano il token dell'app possono contribuire allo stato. Se, per esempio, un team usa quel token in Postman per chiamare una versione deprecata, il report può registrare anche quella chiamata.
Webhook: cosa guardare prima che diventino un incidente
Per i webhook Shopify mostra volumi, tempi di risposta, percentuale di fallimento e singole consegne. La documentazione distingue tra un indicatore “High” sul grafico e l'alert critico Webhook failures: quest'ultimo usa una soglia più severa, cioè oltre lo 0,5% di consegne fallite su almeno 500 consegne in 24 ore.
Quella soglia non va letta come un obiettivo da sfiorare. Serve a capire quando Shopify considera il problema abbastanza consistente da mettere a rischio le subscription webhook. Se gli errori persistono, Shopify ritenta le consegne e può arrivare a rimuovere la subscription, interrompendo la ricezione di quel topic.
Il metodo più utile è quindi partire dallo store e dall'ora in cui il merchant ha segnalato il problema, poi leggere le consegne in ordine. Questo permette di separare più rapidamente endpoint irraggiungibili, status code non corretti e problemi legati al contenuto della richiesta.
Performance nell'admin: non è la velocità del backend
La sezione Admin performance misura tre Core Web Vitals sulle pagine dell'app nell'admin Shopify: LCP, INP e CLS. Questi dati vengono misurati nel browser del merchant, non sul server dell'app.
È una distinzione pratica. Un backend che risponde velocemente non basta se la pagina embedded resta lenta da renderizzare, reagisce tardi alle interazioni o sposta elementi durante il caricamento.
Shopify usa gli stessi Core Web Vitals anche nel programma Built for Shopify, ma il Dev Dashboard e la valutazione Built for Shopify non sono la stessa cosa: la seconda usa una propria finestra di 28 giorni e richiede un numero minimo di misurazioni. La valutazione mostrata nella card non va quindi interpretata come verdetto definitivo sullo status Built for Shopify.
I limiti dei log che bisogna conoscere
I log sono molto utili, ma non sono un sistema di osservabilità universale. Shopify conserva i log per 30 giorni e una singola finestra di ricerca può coprire al massimo 7 giorni. Su intervalli ampi, inoltre, la tabella può mostrare un campione invece di ogni evento corrispondente; quando succede, l'interfaccia lo segnala.
Anche i payload hanno limiti: request e response body molto grandi possono essere troncati. Alcuni dati delle Functions possono dipendere dagli scope disponibili o dall'accesso allo store.
Il limite più importante è concettuale: i log registrano quello che Shopify vede. Una richiesta fatta direttamente dal browser del merchant al backend proprietario dell'app non passa necessariamente dai sistemi osservati dal Dev Dashboard. Una timeline vuota, quindi, non dimostra da sola che non sia successo nulla.
Un flusso di debugging semplice
Quando un'app ha un'anomalia, userei il Dev Dashboard come primo livello di evidence, con questo ordine:
- identificare lo store e il momento del problema, evitando di partire da un grafico globale;
- controllare gli alert, in particolare deprecazioni, webhook e Function errors;
- aprire Operations per capire se l'anomalia riguarda API, webhook o Functions;
- scendere nei Logs già filtrati e leggere gli eventi in sequenza;
- verificare ciò che manca: backend proprietario, database, code, servizi esterni e browser client-side quando il problema non passa da Shopify;
- chiudere con un readback reale, non con il semplice fatto che l'errore sia sparito dal codice.
Questo approccio è coerente anche quando si lavora con Shopify Functions e logica custom: metriche e log servono a restringere il campo, ma la verifica finale deve restare sul comportamento effettivo dell'app.
Cosa non sostituisce il Dev Dashboard
Il Dev Dashboard copre bene la parte che Shopify può osservare direttamente. Non sostituisce però automaticamente i log del proprio backend, il monitoraggio del database, gli errori di servizi terzi o una strategia di alerting interna quando l'app ha componenti esterni alla piattaforma.
Per una piccola app Shopify può ridurre molto il lavoro necessario per capire cosa succede sul lato piattaforma. Per un'architettura più complessa diventa invece una fonte da correlare con gli altri segnali tecnici.
Perché interessa anche al merchant
Il merchant non deve usare il Dev Dashboard per ottenere un vantaggio. Il valore sta nel fatto che chi mantiene l'app può arrivare più rapidamente a evidenze legate allo store specifico: una consegna webhook fallita, una chiamata API problematica, una Function in errore o una regressione della pagina nell'admin.
È anche un buon criterio per valutare il metodo di sviluppo: una correzione non dovrebbe finire con “la modifica è stata deployata”. Dovrebbe finire con la verifica che l'evento atteso sia tornato a funzionare nel runtime reale.
La regola operativa
Usare il Dev Dashboard per ridurre il campo del problema, non per dichiarare automaticamente che il problema è risolto. Alert, metriche e log sono evidence preziose, ma vanno lette insieme ai limiti di visibilità del sistema e seguite da una verifica reale della funzione coinvolta.
Per chi sviluppa app Shopify, l'aggiornamento del settembre 2026 rende questo percorso più diretto: meno passaggi tra pannelli diversi, più continuità tra indicatore, log ed evento specifico.
