Shopify's September 25, 2026 changelog adds filterable logs and health metrics for custom apps in the Developer Dashboard, covering API request volume, error rates, webhook delivery health and embedded admin page load speed, each with a clear threshold. You can investigate incidents by reading these aggregate signals first, then narrowing the single filterable stream to identifiers and timestamps rather than customer payloads.
What exactly changed in the Developer Dashboard?
Shopify's changelog states that the Developer Dashboard now shows how custom apps perform, not only how they are set up. Opening any custom app reveals API request volume, error rates, webhook delivery health and embedded admin page load speed, and each measurement has a clear threshold so you can tell good from bad at a glance. A single filterable stream holds every API request, webhook delivery and app event, and a new home page shows what needs attention across all apps. Agencies and developers who build your custom apps see the same data. Official source
That framing matters for incident work. The dashboard is positioned as a performance surface with thresholds, not as a customer-record browser. The changelog does not describe a log export format, a retention window, a field-level schema or a redaction control, so treat those as unknowns to verify in your own app rather than assumed features.
Why is a filterable log stream a privacy question?
A log stream that captures API requests, webhook deliveries and app events can contain whatever your app sends or receives. If your code writes full request bodies, customer email addresses, order notes, shipping addresses or access tokens into log lines, the convenience of one searchable stream becomes a data-protection problem. The official announcement does not promise automatic masking, so the safe assumption is that visibility reflects what your app emits.
The practical rule is separation of concerns: use the dashboard's health metrics to locate the failure, and use identifiers rather than payloads to confirm it. A webhook delivery failure can usually be diagnosed from the delivery status, the topic, the timestamp and your own internal correlation ID. You rarely need the customer's name to know that a webhook returned an error.
A diagnostic method you can run in order
This sequence moves from aggregate to specific, so you avoid pulling personal data into a debugging session unnecessarily.
- Read the health metrics first. Check API request volume, error rates, webhook delivery health and embedded admin page load speed against their thresholds. This tells you whether the incident is broad or narrow before you open any log line.
- Check the home page for scope. If several apps are flagged, the cause may sit in a shared dependency rather than one app. If only one is flagged, stay with that app.
- Filter the stream by time window. Start with the incident window plus a small margin. A narrow window reduces the chance of scrolling past unrelated customer data.
- Filter by event type. Separate API requests, webhook deliveries and app events. A webhook problem and an API problem produce different signatures even when they occur together.
- Correlate with your own identifiers. Match on your internal order ID, job ID or correlation token rather than on customer attributes. This keeps the investigation anchored to system behaviour.
- Record the finding, not the payload. Write down the error class, the endpoint or topic, the timestamp and the threshold breached. That is enough for a fix and for an incident note.
- Fix, then re-check the metric. The threshold gives you a before-and-after signal without needing to re-read raw events.
Example: a webhook backlog (hypothetical)
Suppose an app that syncs order updates shows webhook delivery health outside its threshold, while API request volume and embedded admin page load speed stay normal. In this hypothetical scenario, the pattern points to delivery rather than to API capacity or admin rendering. Filtering the stream to webhook deliveries in the incident window, then grouping by topic and status, would show whether failures cluster on one topic. You would confirm the affected orders using your own internal IDs, then inspect the handler for that topic. No customer name, address or payment detail is needed at any step. The figures here are illustrative only.
What should you verify rather than assume?
Because the changelog does not specify log retention, export options or field-level controls, verify these in your own environment before you rely on them during an incident:
- What your app actually writes into log lines, including error handlers and third-party libraries.
- Whether your logging pipeline copies data elsewhere, which would extend the exposure beyond the dashboard.
- Who on your team and at your agency can see the same data, since the changelog notes agencies and developers see the same view.
- Whether your internal access rules match that shared visibility.
If you cannot confirm a control, treat it as absent and design the investigation around identifiers instead.
How does this fit alongside other recent Shopify changes?
This release is about operating custom apps, not about storefront configuration. It is separate from theme, checkout, customer-account, catalog and channel work, which draw on different data than app logs. Keep the boundaries clear: app logs diagnose app behaviour, not merchandising or channel quality.
What remains uncertain?
The changelog is a product announcement, not a technical specification. It does not state retention periods, whether logs can be exported, whether thresholds are configurable, or whether any automatic redaction exists. It also does not define what counts as an app event in every case. Those gaps mean your incident runbook should include a verification step: confirm in your own dashboard what fields appear, then decide what your app is allowed to write. For UK and US teams, the operational takeaway is the same: the dashboard gives you faster triage, but the privacy outcome depends on what your code logs, not on the dashboard alone.
Follow-up questions
Can I use the filterable stream to find a specific customer's failed order?
You can, but it is usually the wrong first move. Diagnose with metrics and event types, then correlate using your own internal order ID. Searching by customer attributes pulls personal data into a debugging context that may not need it, and the changelog does not describe masking controls.
Do agencies and in-house developers see different data?
The changelog states that agencies and developers who build your custom apps see the same data. That makes access review a shared responsibility: if an external partner can see the same stream, your logging rules should assume that audience.