Console Guides

Monitoring

Monitoring is the operational health view for your project: on-chain block scanner lag, a usage snapshot, request performance, an audit log of account and infrastructure actions, and threshold-based alerts — across four tabs.

Find it

Monitoring is in the sidebar under the Operations group.

Overview

Monitoring Overview tab with the tab bar, stat cards, block scanners table, usage panel, and daily breakdown table marked
Overview — block scanner sync, usage, and performance in one glance
  1. Switch between the four tabs — this page covers all of them below.
  2. Refresh re-fetches every source on the current tab (and the audit log if you're on that tab).
  3. Success rate and avg response time come from request performance data; block scanners counts configured chains; active alerts counts alerts with isActive true.
  4. One row per configured chain, showing the last scanned block versus the chain's current block. Lag above the configured threshold flags the row High lag; a row with no lag shows Synced. A project with no wallet chains configured shows no rows here — that's expected, not an error.
  5. API calls and storage for the selected window, followed by request counts, success/error split, min/max response time, and a top-endpoints table when the period has enough traffic to aggregate.

Below the two cards, Daily breakdown lists API calls and storage per calendar day for the current usage window.

Audit Logs

Monitoring Audit Logs tab with the Action, Resource, and User ID filters, Apply filters button, and the log table marked
Audit Logs — a running record of account and infrastructure actions
  1. Narrow by Action (e.g. backup.create, api_key.create), Resource, or a specific User ID.
  2. Click to apply the filters above; clearing the fields and applying again resets to page 1.
  3. Each row shows when an event happened, a human-readable activity title and detail, the machine action string, which user triggered it, and which project it belongs to. Actions like backup.create and data.delete land here automatically — you don't configure what gets logged.

Errors

Monitoring Errors tab with the error types breakdown card and the error log table marked
Errors — grouped error types alongside the raw event log
  1. A count per distinct error/event type recorded for this project, most useful for spotting one type spiking.
  2. The same events as a paginated table — time, type, endpoint (when recorded), user, and project. A quiet project can legitimately show no rows here.

Alerts

Monitoring Alerts tab with the alerts table and the create alert form marked
Alerts — existing alerts on the left, the create form on the right
  1. Name, condition, threshold, notification action, and whether the alert is active. Conditions and thresholds are free text/number — there's no fixed enum, so name them descriptively (e.g. api_error_rate at threshold 25).
  2. Pick the project the alert applies to, set a condition, threshold, and action (e.g. email), then click Create alert. Alert count per project is capped by your plan — the form disables with a limit message once you're at capacity.
Note
The Errors tab and the Analytics page's error distribution share the same underlying event data — cross-check there for the same events grouped by time period instead of by type.