The Operations dashboard provides visibility into your application's performance, errors, and resource usage through a collection of pre-built charts.
Charts
Overview
HTTP status codes
Tracks HTTP requests received by your application over time, grouped by HTTP status code.
This includes requests made from your application's internal business logic to your application's API, including both Public API and Internal API requests.
Note that HTTP status code 101 is returned by your application when processing WebSocket upgrade requests. Websockets are used by the Gadget API to implement database transactions, as well as Live Queries.
Errors
Shows all errors occurring in your application over time, grouped by error code or message. This chart includes all errors, including those that may be logged at the warn level, or errors that will be retried.
Platform operations
Tracks the number of billable platform operations over time.
Active CPU time
Shows the active CPU time in seconds for your application over time.
Active CPU time describes the amount of serverless CPU time that your application has used where your application was actively running on a serverless worker. Time spent waiting on IO, like database reads or writes, API calls, or LLM invocations isn't included in this metric.
For the wall-clock time that your application has spent processing requests, see the Request time by trigger metric.
Actions attempted
Shows all action executions over time, grouped by action type or action identifier.
Scheduled actions attempted
Tracks scheduled action executions over time, grouped by action identifier.
Trigger count
Displays the count of different trigger types (Routes, Actions, Syncs, etc.) over time.
Request time by trigger
Shows total request time grouped by trigger type.
Request time describes the amount of wall-clock time that your application has spent processing requests. This measure does not differentiate between the time spent in active use of the CPU or waiting on IO. Instead, it measures the real-world time that each request takes. See Active CPU time for a measure of the billable Active CPU time metric.
Request rate limit usage
Monitors how close your environment is to exceeding your environment's request rate limit.
Read more about request rate limits in the Rate limits guide.
Action maximum runtimes
A table showing average and maximum execution times for each action.
This chart is helpful for knowing if it is safe to reduce the timeout of an action. If an action is consistently running for less time than its timeout, you can safely reduce the timeout to reduce the risk of runaway actions.
Worker Health
Gadget monitors worker health metrics for each serverless worker powering your application. Read more about how workers operate, their lifecycle, and how Gadget manages them in the Runtime environment guide.
Worker event loop utilization
Shows the maximum event loop utilization percentage for each serverless worker powering your application.
Event-loop utilization is a Node.js-specific measure of how busy your workers are. A value of 100% means the event loop is fully utilized, and 0% means the event loop is idle. Ideally, event loop utilization should be below 75%, as higher utilization can lead to event loop blocks, which causes performance and responsiveness issues.
Read more about the Gadget runtime environment in the Runtime environment guide.
Worker memory usage
Tracks the maximum memory usage for each worker instance.
This metric measures the system-level, non-evictable memory usage for each worker instance. This includes memory used by the Node.js process, like in-flight data, application code, and any memory allocated by native extensions. This also includes any memory consumed by subprocesses, like Playwright browsers or similar.
Read more about the Gadget runtime environment in the Runtime environment guide.
Worker CPU usage
Shows the average CPU usage for each worker instance.
This metric measures the system-level CPU usage for each worker instance. This includes CPU used by the Node.js main thread, CPU used by Node.js worker threads, and CPU used by any subprocesses, like Playwright browsers or similar.
Read more about the Gadget runtime environment in the Runtime environment guide.
Worker count
Displays the number of distinct worker instances running your application over time.
This metric tracks the number of distinct worker instances running your application over time. This includes both workers that are actively processing requests, and workers that are idle and waiting for requests. You may see the active worker count fluctuate as load on your application goes up and down, or as Gadget starts and stops workers for platform maintenance.
Read more about worker lifecycle and scaling in the Runtime environment guide.
Database
Database queries
Tracks the total number of database queries over time, including both read and write queries.
Database storage
Shows database storage usage over time, either as a total or broken down by model.
Database storage is only recorded about once an hour, so it may take some time for this chart to reflect changes as you make them.
Database rate limit usage
Tracks database query rate limit usage over time.
Read more about database rate limits in the Rate limits guide.
Database bytes read
Tracks the total bytes read within the database over time.
This metric shows how many bytes Postgres has to read in order to fulfill your queries. For simple read queries like findById or findOne, this will be very small. For more complex read queries like findByFilterSort, this will be larger, as Postgres must scan multiple indexes and the table heap to fulfill your query. For computed fields and views, this can be even larger, as Postgres may need to scan large parts of various tables to fulfill your query. This metric is instrumented within Postgres itself, and tracks exactly how many bytes the database had to read from any of its storage subsystems to fulfill your query.
Database read queries
Tracks the total number of database read queries over time.
Database bytes written
Shows the total bytes written within the database over time.
This metric shows how many bytes Postgres has to write in order to fulfill your write queries. This metric includes any bytes Postgres needs to write to the table heap, the WAL, and the table's indexes. Drivers of this metric are writing many rows, or writing to models with many fields, or specifically writing to models with many indexed fields.
This metric is instrumented within Postgres itself, and tracks exactly how many bytes the database had to write to any of its storage subsystems to fulfill your query.
Fields indexed for sort and filter
A table showing the sort and filter index usage for each model field.
This metric shows the size of the indexes for each of your model's fields from the selected time range. This is helpful for identifying if your application ever sorts or filters on a given field. If it doesn't, the index for these fields are unused and can be disabled to reduce costs.
File storage
Show the total bytes stored in cloud storage by the application over time.
Note that this metric is only recorded about once an hour, so it may take some time for this chart to reflect changes as you make them.
Search
Search requests
Tracks search query volume over time, grouped by model.
Search storage
Shows the storage used by search indexes over time, either as a total or broken down by model.
Note that this metric is only recorded about once an hour, so it may take some time for this chart to reflect changes as you make them.
Search read queries
Tracks the total number of search read queries over time.
Search bytes written
Tracks the total bytes written to search indexes over time.
Search write queries
Tracks the total write queries written to search indexes over time.
Models indexed for search
A table showing which models have search indexes, their current storage usage, and search usage count.
This table is useful for knowing which models can have their search indexes safely disabled to reduce costs. If a model has received no search queries recently, you can likely disable search for the model.
Gadget doesn't expose field-level search index usage currently -- just model-level search index usage data is available.
Background Actions
Action attempts over time
Shows all background action attempts, grouped by status, queue, or action.
Note that this chart includes all action attempts, including those that were retried or cancelled. One background action can have many attempts, and each attempt is counted separately.
Queued background actions
Displays the peak number of background actions waiting in queues.
Note that this chart counts the number of waiting background actions, exclusive of the number of background actions that were actively running at each point in time.
Failed action attempts over time
Shows the number of failed background action attempts over time, grouped by queue, action, or retry attempt number.
Running background actions
Shows the peak number of background actions currently running, grouped by queue.
Note that this chart shows instantaneous concurrent actions at each point in time. This count shows how many actions were running, not how many actions ran total.
Cancelled background actions
Tracks background actions that were cancelled, grouped by queue, action, or retry attempt number.
Traffic
Route requests
Shows the number of requests to your HTTP routes over time.
Route errors
Shows errors specifically related to HTTP routes, grouped by HTTP response status code.
Outbound bandwidth
Tracks the total outbound bandwidth transferred from your application in GBs.
Average page load time
Monitors the average and maximum page load times for your frontend routes in seconds.
Note that this metric requires the presence of the web-performance.min.js script that is included in Gadget applications by default to work. If that script has been removed, this metric will not be available.
Shopify
Shopify API calls
Tracks all outbound API calls to Shopify's API, grouped by status code or by Shopify install.
Rate limit errors
Shows Shopify API rate limit errors (HTTP 429 status codes) over time.
Webhooks
Shows the count of incoming Shopify webhook payloads over time, grouped by webhook topic or by install.
Webhook triggered actions
Shows the count of actions that were triggered by Shopify webhooks over time, grouped by topic, model, action, or install.
Note that this chart includes all actions triggered by Shopify webhooks, or by Gadget's internal missed-webhook reconciliation process. The periodic webhook reconciliation can cause spikes on this chart, as it will trigger actions for all missed webhooks when the background process runs once per day.
Sync triggered actions
Shows the count of actions triggered by Shopify sync operations over time, grouped by model, action, or install.
Reconciliation triggered actions
Shows actions triggered by webhook reconciliation processes, grouped by model, action, or install.
Active installs
Tracks the number of active Shopify installs over time.
Note that the data for this metric is only recorded about once an hour, so it may take some time for this chart to reflect changes as you make them.