Operations dashboard 

The Operations dashboard provides visibility into your application's performance, errors, and resource usage through a collection of pre-built charts.

Overview 

HTTP status codes 

Tracks HTTP requests received by your environment over time, grouped by HTTP status code.

This includes requests made from your app's internal business logic to your app's API, including both Public API and Internal API requests.

Note that HTTP status code 101 is returned by your environment 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 environment over time. This includes errors that may be logged at the warn level and errors that will be retried.

• Breakdowns
  • Code: Groups errors by error type or code.
  • Message: Groups errors by the specific message emitted.
  • Source: Groups errors by the source of the request that encountered the error, such as the webhook topic, background action, or action.

Platform operations 

Shows the billable platform operations your environment generates over time. These operations consume credits.

• Breakdowns
  • Source type: Groups operations by category of platform operations.
  • Source: Shows the specific job, action, or workflow generating the operations.
  • Install: Shows the tenant responsible for the operation.

Active CPU time 

Shows the amount of active serverless CPU time used by your application while code was actively running. Time spent waiting on IO (such as database queries, API calls, or LLM requests) is not included in this metric.

This chart displays two types of CPU usage:

• CPU time: CPU time used within your plan's normal concurrency limits, billed at the standard rate.
• Surge CPU time: CPU time used above your concurrency limit to run high-priority requests. Surge CPU time is billed at a higher rate and only applies while surge capacity is in use.

Request rate limit usage 

Monitors how close your environment is to exceeding its request rate limit over time.

• Breakdowns
  • Request type: Breaks usage down by the type of request consuming the limit.
    • External: Requests to your app's API that originate outside the Gadget runtime, such as browsers, external services, and third-party API clients.
    • Internal: Requests to your app's API that originate inside the Gadget runtime, such as action code and api.* calls.
    • Background: Background actions starting execution after an api.enqueue call.

Read more about request rate limits in the rate limits guide.

Actions attempted 

Shows the total number of actions attempted over time. This includes every action invocation Gadget attempts to run, regardless of outcome.

• Breakdowns
  • Action type: Broken down by action type, as model create, model update, model delete, model custom, or global.
  • Action: Breaks attempts down by the action's API identifier.
  • Install: Breaks attempts down by the install the action is associated with.

Scheduled actions attempted 

Shows the total number of action attempts initiated by the scheduler trigger over time. This includes every scheduled action invocation Gadget attempts to run, regardless of outcome.

• Breakdowns
  • Action: Breaks attempts down by the specific action being invoked.

Worker health 

Gadget monitors runtime health metrics for each serverless worker powering your app. Learn more about worker lifecycle and management in the runtime environment guide.

Worker event loop utilization 

Shows the maximum event loop utilization percentage for each serverless worker powering your environment.

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 Node.js event loop in the Node.js documentation.

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. This includes both read and write queries.

• Breakdowns
  • Model: Groups by the models queried.
  • Query type: Groups by read and write operations.

Database bytes read 

Tracks the total bytes read within the database over time.

This metric shows how many bytes Postgres reads to fulfill your queries:

• Simple read queries (such as findById or findOne) read very little data.
• More complex read queries (such as findByFilterSort) read more data, as Postgres must scan multiple indexes and the table heap.
• Computed fields and computed views may read significantly more data, since Postgres may need to scan large portions of multiple tables.

This metric is instrumented directly within Postgres and tracks the exact number of bytes read from any database storage subsystem to fulfill each query.

• Breakdowns
  • Model: Groups by the models queried.

Database read queries 

Tracks the total number of database read queries executed over time.

• Breakdowns
  • Model: Groups by the models queried.

Database bytes written 

Tracks the total bytes written within the database over time.

This metric shows how many bytes Postgres writes to fulfill write queries. This includes bytes written to:

• The table heap
• The WAL
• The table's indexes

Common drivers of this metric include writing many rows, writing to models with many fields, or writing to models with many indexed fields.

This metric is instrumented directly within Postgres and tracks the exact number of bytes written to any database storage subsystem to fulfill a query.

• Breakdowns
  • Model: Groups by the model being written to.

Database write queries 

Tracks the total number of database write queries executed over time. Write queries include operations that create, update, or delete records.

• Breakdowns
  • Model: Groups write queries by the model being written to.

Fields indexed for sort and filter 

Shows the sort and filter index usage for each model field.

This metric shows, for the selected time range:

• The size of the index for each field
• How many times the index was used
• When the index was last used

This helps identify fields your environment never sorts or filters on. Indexes for unused fields can be disabled to reduce costs.

Database rate limit usage 

Tracks database rate limit usage over time for your environment.

The database rate limit caps the total amount of time spent running database queries within a 10 second window. Usage is measured in milliseconds, and each database query consumes rate limit capacity for the duration of time it runs.

Database storage 

Shows database storage usage over time for your environment.

• Breakdowns
  • Model: Breaks storage usage down by individual models.

Learn how database storage is billed and prorated in the billing guide.

File storage 

Shows file storage usage over time for your environment.

• Breakdowns
  • Model: Breaks storage usage down by individual models.

Learn how file storage is billed and prorated in the billing guide.

Search 

Search requests 

Tracks the volume of search queries executed over time.

• Breakdowns
  • Model: Groups search requests by the model being queried.

Search read queries 

Tracks the total number of search read queries executed over time.

Search read queries occur when your environment reads from the search index to retrieve matching records.

Search bytes written 

Tracks the total number of bytes written to your environment's search indexes over time.

This metric reflects how much data is written to search indexes as records are created, updated, or reindexed.

Search write queries 

Tracks the total number of search write queries executed over time against your application's search indexes.

Search write queries occur when records are added to, updated in, or removed from the search index.

Models indexed for search 

Shows search index usage for each model in your application.

This table shows, for the selected time range:

• The size of the search index for each model
• How many times the model's search index was used
• When the model's search index was last used

This helps identify models your application does not search on. Search indexes for unused models can often be disabled to reduce costs.

Search storage 

Shows the storage used by Elasticsearch search indexes backing your environment over time.

• Breakdowns
  • Model: Breaks storage usage down by individual models.

Background actions 

Background action attempts 

Shows all background action attempts over time.

This chart counts every attempt to run a background action. A single background action may have multiple attempts due to retries, and each attempt is counted separately. Cancelled attempts are also included.

• Breakdowns
  • Queue: Groups attempts by the queue the action ran in.
  • Action: Groups attempts by the specific background action.

Queued background actions 

Displays the peak number of background actions waiting in queues over time.

This chart shows how many background actions were queued and waiting to run at each point in time. Actions that were actively running are not included in this count.

• Breakdowns
  • Queue: Breaks queued actions down by queue.

Failed background action attempts 

Shows the number of failed background action attempts over time.

This chart counts every failed attempt to run a background action. If an action is retried multiple times and fails repeatedly, each failed attempt is counted separately.

• Breakdowns
  • Queue: Groups failed attempts by the queue they ran in.
  • Action: Groups failed attempts by the specific background action.
  • Retries: Groups failed attempts by retry attempt number.

Running background actions 

Shows the peak number of background actions running at each point in time.

This chart reflects instantaneous concurrency, not total executions. It shows how many background actions were actively running at a given moment, not how many actions ran overall.

• Breakdowns
  • Queue: Breaks running background actions down by queue.

Cancelled background actions 

Tracks background action attempts that were cancelled over time. These actions are explicitly cancelled and are no longer eligible to run. Each cancelled attempt is counted separately.

• Breakdowns
  • Queue: Groups cancelled actions by the queue they were in.
  • Action: Groups cancelled actions by the specific background action.
  • Retries: Groups cancelled actions by retry attempt number.

Traffic 

Route requests 

Shows the number of requests made to your environment's HTTP routes over time.

This includes requests to both web routes and API routes handled by your environment.

• Breakdowns
  • Route: Breaks requests down by individual route.

Route errors 

Shows errors related to HTTP routes over time.

This chart includes requests to both web routes and API routes that resulted in error responses.

• Breakdowns
  • Code: Groups errors by HTTP response status code.
  • Message: Groups errors by the error message returned by the route.

Outbound bandwidth 

Tracks the total bandwidth served from your app's edge network over time. This is the amount of data your environment serves to clients.

This includes:

• GraphQL responses served by your API
• HTML responses served by routes
• Raw file data served from File storage

Average page load time 

Monitors the average and maximum page load times for your environment's routes.

This metric reflects how long web and api routes take to load for end users and helps identify slow or inconsistent performance.

This metric requires the web-performance.min.js script, which is included in Gadget applications by default. If this script has been removed, page load timing data will not be available.

• Breakdowns
  • Route: Breaks page load times down by individual routes.

Shopify 

Shopify API calls 

Tracks all outbound API calls made from your environment to Shopify's API over time.

This includes GraphQL requests made to the Shopify admin API and when fetching non-webhooked fields.

• Breakdowns
  • Status code: Groups API calls by HTTP response status code.
  • Install: Groups API calls by the Shopify shop (install) the calls are made for.

Shopify rate limit errors 

This chart tracks API calls to Shopify that returned HTTP 429 (SHOPIFY_RATE_LIMIT_ERROR: too many requests) responses, indicating that Shopify rate limits were exceeded.

• Breakdowns
  • Install: Groups rate limit errors by the Shopify shop (install) the calls were made for.

Webhooks 

Shows the count of incoming Shopify webhook payloads received by your environment over time.

• Breakdowns
  • Topic: Groups webhook payloads by the Shopify webhook topic.
  • Install: Groups webhook payloads by the Shopify shop (install) they were sent for.

Webhook triggered actions 

Shows the count of actions triggered by Shopify webhooks over time.

This chart includes actions triggered directly by incoming Shopify webhooks, as well as actions triggered by Gadget’s internal missed-webhook reconciliation process.

Because webhook reconciliation runs periodically, it may trigger actions for multiple missed webhooks at once. This can result in periodic spikes in this chart, even when real-time webhook traffic is steady.

• Breakdowns
  • Topic: Groups triggered actions by Shopify webhook topic.
  • Model: Groups triggered actions by the model affected.
  • Action: Groups triggered actions by the specific action that ran.
  • Install: Groups triggered actions by the Shopify shop (install).

Sync triggered actions 

Shows the count of actions triggered by Shopify syncs over time.

These actions are generated when Gadget runs Shopify syncs to fetch or reconcile data from Shopify, rather than from real-time webhooks.

• Breakdowns
  • Source: Groups triggered actions by the sync source that initiated them.
  • Install: Groups triggered actions by the Shopify shop (install).

Reconciliation triggered actions 

Shows the count of actions triggered by Shopify webhook reconciliation over time.

Webhook reconciliation runs periodically to detect and recover missed Shopify webhooks. When missing events are found, Gadget triggers the appropriate actions to bring your data back into sync.

Because reconciliation runs in batches, this chart commonly shows periodic spikes when the reconciliation process executes.

• Breakdowns
  • Source: Groups triggered actions by the reconciliation source that initiated them.
  • Install: Groups triggered actions by the Shopify shop (install).

Active installs 

Tracks the number of active Shopify installs for your environment over time.

An active install represents a Shopify shop that currently has your Shopify app installed.