Read the dashboard
The dashboard is the universal first stop. Open the App, look at four numbers, decide whether anything needs your attention today. This page explains what those numbers mean and what to watch for over time.
The four numbers that matter
Cache hit rate
The share of read traffic the Gateway served from cache rather than forwarding to the warehouse. Trends matter more than the absolute number — a tenant with mostly ad-hoc reads will naturally hit a lower rate than one with a repeating BI workload, and that's fine.
A sudden drop is the most common signal of a rule that stopped matching — usually because a tool started emitting slightly different SQL, a parameter was added, or a schema changed. Click into the traffic page and look for misses on statements that used to hit.
Statements through the Gateway
The total volume of statements the Gateway saw in the time window. A baseline you watch for shape, not magnitude — sharp increases without a known release usually mean a runaway report or a script in a loop; sharp decreases usually mean a BI tool has stopped routing through Airbrx and is going direct to the warehouse.
Warehouse-bound statements
The statements that were forwarded to the warehouse — the complement of the cache-hit count. Watch the ratio against total volume. Rising warehouse-bound volume without a corresponding rise in total volume usually means cache rules aren't catching what they used to.
Savings tile
The savings tile is a projection, not a measurement, and it is worth understanding exactly how it is built before you quote it to anyone.
It multiplies your cache hit rate by the monthly warehouse
spend you typed in — the figure on your account settings,
which falls back to a placeholder if you have not set one. That is
the whole calculation. Airbrx does not read your Snowflake
QUERY_HISTORY, your Databricks billing tables, or any
other billing surface, so it has no measured cost signal to work
from. Nothing in the platform knows what a query actually cost you.
Two things follow. First, set your monthly spend accurately, because the tile is only as good as that number. Second, treat the result as a directional estimate: real savings depend on which queries get cached, and small frequent reads cache far better than large joins, so an identical hit rate can be worth very different amounts.
What is measured, and what you can quote without qualification, is the hit rate itself and the response-time improvement. Both are counts and timings observed on your real traffic. If you need a defensible cost figure, take the measured hit rate to your warehouse's own billing data and do the attribution there.
Where to look next when something looks off
| What you see | Where to look |
|---|---|
| Hit rate dropped suddenly | The traffic page — sort by misses on previously-hit statements. |
| Volume dropped to zero | The BI tool's connection settings. Confirm it's still pointed at the gateway address. |
| Volume spike from one user | The traffic page, filtered by user. Usually a script in a loop, not malicious. |
| Hit rate is high but warehouse spend isn't dropping | The hits may be on cheap queries and the misses on expensive ones. Use the analytics API to slice by warehouse cost rather than count. |
| New tenant with no traffic yet | The point-a-BI-tool walkthrough — connection probably hasn't landed yet. |
What the dashboard doesn't tell you
Per-rule breakdowns and per-table heat aren't on the dashboard — those live in the traffic page. The dashboard's job is to be the universal at-a-glance. Build the habit of glancing at it once a day; reach for the traffic page when something on the glance looks off.
Where to go next
- Investigate a statement — drill from the dashboard into a single query's history.
- Build custom reports — when your team needs a metric the dashboard doesn't surface.
- Analytics API reference — endpoints for yearly, daily, and per-user roll-ups.
Open the dashboard
Glance at the four numbers, then come back to the docs when something looks off.
Open in the App