Gadget's new operations dashboard provides charts and tables that help devs investigate errors and inefficient application code.
The operations dashboard helps you understand how your app behaves, providing up-to-date information about your app’s performance, errors, and resource usage, while you build and after you deploy.
Because Gadget runs every development environment on real cloud infrastructure, operational signals appear early. Slow queries, inefficient actions, background action retries, and excess resource usage (especially excessive Shopify syncs) don’t wait for production. The operations dashboard surfaces those signals in a single interface, so you can understand performance and cost as you build and after you have deployed to production.
The database view in the ops dashboard:
A clear picture of how your application runs
The ops dashboard provides visibility into your application’s performance, errors, and resource usage through a collection of pre-built charts and tables. Together, they show how real requests move through your system.
Instead of interpreting isolated metrics, you can see how traffic, execution time, failures, and infrastructure usage change over time, and how they relate to one another.
Because charts share a selected time range, you might notice a spike in database activity driven by a specific query pattern, then look at the same time window to see how that change affected background processing, search indexing, or overall compute usage. Keeping these signals aligned makes it easier to reason about cause and effect across the hosted infrastructure.
So, what does the dashboard show me?
The operations dashboard includes pre-built charts that span the full lifecycle of a running application:
- App overview: HTTP status codes, errors, actions run, CPU time, and number of platform operations performed.
- Worker health: Worker CPU usage, memory consumption, event loop utilization, and how they all scale. (Read the docs to learn more about workers and the Gadget runtime environment.)
- Database usage: Query volume, storage, read and write volume, and how they correlate to rate limits, index usage, and file storage size.
- Search usage: Request volume, read/write activity, storage and index usage.
- Background actions: Number of action attempts, and enqueued, failed, cancelled, and running action counts.
- Traffic behaviour: Route requests, bandwidth, and average page load times.
- Shopify activity (Shopify apps only): Number of Shopify API calls, rate limit errors, webhooks, syncs, and active installs.
These charts are displayed on a shared timeline, making it easy to move between application behavior, infrastructure usage, and cost without losing context.
If you want to learn more about individual tables, we have descriptions of each table in our docs.
How engineers actually use the operations dashboard
Engineers don’t usually open the ops dashboard to look at a single metric. They use it to understand why the system is behaving a certain way and what changed. The dashboard is designed to help engineers reason about performance, errors, and resource usage together, instead of in isolation.
A few common workflows:
- Tracing a performance regression After a deploy, request times start creeping up. By looking at traffic, execution time, and database activity on the same timeline, you can quickly see whether the slowdown is coming from increased user activity or long-running logic in your actions or routes.
- Understanding background work under load As traffic increases, background actions may start to queue or take longer to complete. The dashboard makes it easy to see when workers are spending more time under load, whether jobs are piling up, how often background actions need to be retried, and how that correlates with CPU and memory usage.
- Catching inefficiencies early in development Because the same dashboard is available in development environments, you might notice an unexpected spike in database reads, retries, or search indexing while building a feature. Seeing that behavior early makes it easier to fix inefficient queries or actions before they become production problems.
- Investigating errors with context When errors increase, the dashboard shows what else was happening at the same time: traffic changes, worker saturation, rate limits, or resource pressure. That context helps distinguish between transient issues and problems rooted in application behavior.
- Making informed performance and cost tradeoffs By connecting resource usage to real application activity, engineers can see whether increased compute or database usage is driven by real demand or avoidable work. That makes it easier to decide where optimization is worth the effort and where additional resources are the right tradeoff.
Instead of jumping between logs, metrics, and dashboards, the operations dashboard gives engineers a single, shared view of how their application behaves as it’s built and as it scales.
Resource usage you can reason about
Because Gadget runs every environment on hosted cloud infrastructure, resource usage matters before you hit production. The ops dashboard surfaces how your application uses compute, database, storage, and network resources while you build and test your app, so cost isn’t something you only discover after deploying.
By connecting resource usage to application behavior, the dashboard helps explain changes in your monthly spend. You can see whether increases are driven by real demand, background work, inefficient queries, or long-running actions, and make informed tradeoffs as you iterate. This makes it easier to understand how changes in traffic or code affect your monthly bill before they become a surprise.
The same dashboard is available in development and production environments. Because all Gadget environments run on the same managed runtime, the signals you see while building are the same ones that matter in production.
The result is fewer surprises and an application that’s easier to operate as it scales.
Under the hood, the dashboard is powered by ClickHouse and backed by precomputed materialized views, so you can explore high-volume operational data interactively without slow queries or long load times. The result is a fast, always-on view of how your application behaves across every development and production environment.
Have questions or want to dig deeper? Ask us in our developer Discord or check out our documentation.
Want to learn more about how to use the operations dashboard? See Gadget CTO, Harry Brundage, explain each chart and how to use them:
Top comments (0)