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, or90d - 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
Recommended first pass
When you are diagnosing a new setup:
- start with
All Projects - use the
7dor30dview - look at query volume, estimated cost, and average latency together
- 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.