Apps / Improvement

In the Developer Dashboard,
you can now see the "health" of your custom apps

See API request volume, error rate, webhook delivery health, and embedded admin load speed at a glance, each with thresholds. API requests, webhooks, and app events are combined into a single log stream you can filter to track down root causes.

What's on this page
  1. What's changing (in 30 seconds)
  2. 4 metrics you can view per app
  3. A unified log stream
  4. New home screen and sharing scope
  5. Old vs. new Developer Dashboard
  6. Getting started
  7. 5 key points for developers
  8. 3 practical use cases
  9. One-line summary for proposals

1What's changing

Until now, the Developer Dashboard was where you checked "how" your custom apps were configured for your custom apps.
Starting now, you can also see "whether they're actually working well (performance)" as well.

Before: See configuration

The dashboard focused mainly on checking how your app was configured.

Now: See behavior too

With metrics, thresholds, filterable logs, and a home screen spanning all your apps, you can go from spotting a problem to investigating its cause without leaving the dashboard.

24 metrics you can view per app

Open any custom app to see the following.Each metric has clear thresholds,so you can tell at a glance whether things are good or bad.

API request volume
How much you're calling the API
Error rate
Share of requests that are failing
Webhook delivery health
Whether webhooks are being delivered
Embedded admin load speed
Load speed of pages inside the admin
Illustration: telling "good / bad" at a glance using thresholds Threshold Healthy Needs attention App A: No issues App B: Needs review
The specific threshold values (e.g., what error rate triggers a warning, or how many seconds counts as slow) arenot specifiedin the Changelog. The diagram above is a conceptual illustration.

3A single unified log stream

API requests, webhook deliveries, and app eventsall flow intoa single filterable stream. When your app stops working, you can track down the cause.

API requests Webhook deliveries App events Single log stream Filterable Pinpointing the cause API 200 OK Webhook delivery failed ← the cause App events *Illustrative example only
Which fields you can filter by (status, topic, time range, etc.), how long logs are retained, and whether they can be exported arenot specifiedin the Changelog. Check the documentation for details.

4New home screen and sharing scope

!

A home screen that shows what "needs attention" across all apps

The new home screen brings together every app that needs attention in one place.

The same data for your development partners

Agencies and developers building your custom apps see the same data.

Merchant Custom app owner Same metrics, same logs Developer Dashboard Agency / developer Custom app builder

5Previous vs. new Developer Dashboard

ItemPreviousNow
What you can see Configuration App configuration Configuration + behavior plus performance
Health metrics Not mentioned 4 metrics API volume / error rate / webhooks / load speed
Judging health Not mentioned With thresholds Judge at a glance
Logs Not mentioned Unified Filter API, webhook, and event logs in a single stream
Overview Not mentioned New home Shows action items across all apps
Sharing with build partners Not mentioned The same data is also available to agencies and developers

* The article says this applies to "custom apps." It doesn't say whether public apps are included, and pricing or plan requirements aren't mentioned either.

6How to get started

1

Open dev.shopify.com/dashboard

The new experience starts here. Check the home screen to see which apps need attention.

2

Open a custom app and review its metrics

Check API volume, error rate, webhooks, and load speed against their thresholds.

3

Filter the logs to find the cause

If something looks wrong, find the request or delivery in the unified log stream.

Detailed usage is covered in the official docs (via "Read more in the docs" in the Changelog). Whether any setup is needed to enable it isnot mentioned.

75 key points for developers

1. Three log types unified into one stream

Track API requests, webhook deliveries, and app events in the same stream. Line them up in time order without switching between separate screens or your own logging.

2. Webhook delivery health is visible from Shopify's side

You can diagnose "webhooks not arriving" issues from the sending side (Shopify's delivery status), not just your receiving server's logs.

3. Embedded admin load speed becomes a metric

Load speed of app pages embedded in the admin is now measured. Use it to verify the impact of front-end performance improvements.

API ?

4. No details on values, API access, or alerts

The changelog doesn't specify threshold values, log retention period, external export or API access, or whether alert notifications exist. If you want to integrate this into your monitoring stack, check the documentation.

5. Merchants and developers can discuss issues on the same screen

Agencies and developers see the same data as the merchant.When reporting an incident, you can share "which request failed, and when" as common facts, reducing back-and-forth screenshots and waiting for reproductions.

83 practical use cases

USE CASE 1

Speed up first-line triage of "the integration stopped" incidents

Challenge
When a custom app for inventory or order sync suddenly stops working, it takes time to determine whether it's an API error or undelivered webhooks.
Approach
In the Developer Dashboard, check the app's error rate and webhook delivery health, then filter the unified log stream to pinpoint failed requests and deliveries.
Impact
Quickly narrow down where the problem lies (Shopify's delivery or the app's processing), shortening time to recovery.
Technical notes
API requests, webhooks, and app events share the same stream, so you can trace their sequence over time. Check the docs for details on filter options.
USE CASE 2

Routine health checks for maintaining multiple custom apps

Challenge
When a store has several custom apps, you often only notice which one is failing after a customer complains.
Approach
Regularly review the cross-app "needs attention" items on the new home screen, and prioritize apps whose metrics exceed thresholds.
Impact
Catch issues before customers report them, and set clear maintenance priorities.
Technical notes
Whether alert notifications are available isn't stated. For now, it's safest to assume a "go check the dashboard" workflow and build the check frequency into your maintenance contract.
USE CASE 3

Report client-project quality with shared data

Challenge
Agencies deliver and maintain custom apps for merchants but lack evidence of operational quality, so reporting relies on screenshots or verbal updates.
Approach
Since merchants and agencies can view the same Developer Dashboard data, use error rate, load speed, and similar metrics as shared KPIs in regular reports.
Impact
Both sides discuss the same numbers, making improvement proposals (such as load speed improvements) more persuasive.
Technical notes
Thresholds indicate good vs. bad status, making it easier to explain to non-technical merchants. Whether data can be exported isn't stated.

9One-line summary for proposals

"The Developer Dashboard evolves from a custom app 'settings screen' into a 'health check screen.'
Four metrics with thresholds plus a filterable unified log take you from spotting issues to pinpointing causes, all on one screen."
Merchants and their agency partners can work from the same data."