Dashboard

Browse docs

Dashboard

Tap to expand

Contribute

DashboardUpdated 2026-03-18

Usage and Analytics

Use the dashboard analytics view to understand volume, latency, memory health, and trend changes without dropping into raw API responses first.

The dashboard usage page is the fastest way to answer “is this integration healthy?” without querying multiple operational endpoints by hand.

Open /dashboard/dev/usage when you want a visual view of:

  • total queries
  • token usage
  • estimated cost
  • average latency
  • per-project trends over time
  • memory API health at the org level

How the page is organized

The current page gives you:

  • a project filter
  • a time window switcher for 7d, 30d, or 90d
  • top-level summary cards
  • supporting stats like searches and memories created
  • memory health signals such as success rate and recent trace ids
  • timeseries data for trend analysis

When you are diagnosing a new setup:

  1. start with All Projects
  2. use the 7d or 30d view
  3. look at query volume, estimated cost, and average latency together
  4. only then narrow to a specific project

This prevents you from misreading a global issue as a project-specific one.

What the metrics are good for

Total queries

Use this to confirm whether traffic is actually reaching RetainDB.

Tokens used

Use this to understand workload size, especially if cost looks higher than expected.

Estimated cost

Use this as a directional signal, not as your only billing source of truth.

Average latency

Use this to spot obvious regressions, but do not treat it as the whole story. One slow path can hide inside a decent average.

Memory API health

This is the most useful section when debugging reliability at the org level. It helps you see whether failures, fallbacks, or latency are systemic rather than tied to one request.

What a healthy page usually looks like

  • query volume matches what your app or team expects
  • latency is stable for the chosen time window
  • memory API success rate is high
  • recent trace ids are available when deeper debugging is needed

Common mistakes

Using the analytics page as request-level debugging

This page helps with trends and health, not one exact request. For a single bad request, use trace ids and endpoint-level responses.

Looking at one metric in isolation

High latency with flat volume means something different from high latency during a traffic spike. Always read the cards together.

Filtering to a project too early

If multiple projects are affected, the all-projects view shows the pattern faster.

When to switch to API endpoints

Stay in the dashboard when you want quick operational visibility.

Switch to API endpoints when you need:

  • exportable data
  • automation
  • exact payloads for external reporting
  • breakdowns you want to script

Next step

If you need raw operational endpoints for the same information, go to cache, cost, and usage endpoints. If you are still setting up data and have nothing meaningful to measure yet, return to sources: add, sync, and troubleshoot.

Was this page helpful?

Your feedback helps us prioritize docs improvements weekly.