See the cache work

1. Sign up
2. Claim address
3. Connect warehouse
4. Point a tool
5. First rule
6. Verify

In the App dashboard

Open the tenant page in the App. The dashboard has cache-hit-rate, bytes-served-from-cache, and warehouse-compute-saved tiles — re-run the SELECT from step 5 a few times and watch them tick up. The traffic page logs every statement with its cache outcome (HIT, MISS, BYPASS), the rule that matched it, the user who ran it, and timing. Click any statement for the full set of X-Airbrx-* headers.

The dashboard is the universal verification surface — works for every BI tool, requires no driver inspection, and lives where the FinOps and ops audiences already look.

In your BI tool

Most BI tools surface execution time per query. Run the SELECT from step 5 twice in your tool; the second run should land noticeably faster — the Gateway returns from cache rather than waking the warehouse. Tableau, Power BI, and Excel show this implicitly via refresh time; DBeaver and Python clients show it explicitly in the session log alongside the response headers.

In response headers

The Gateway adds X-Airbrx-* headers to every response — the most concrete proof, if your client surfaces them. The headers a cache hit carries:

What each one tells you:

• HIT — the cache served this. No warehouse compute was charged for this request.
• first-cache-rule — the rule from step 5 is what made the call. Different cache outcomes from different rules will show different IDs here.
• your-slug — confirms the gateway address is yours.
• X-Airbrx-Execution-Time — proxy time (how long the Gateway spent on this request). For cache hits, typically well under 50ms.
• X-Airbrx-Warehouse-Execution-Time — the original cost of running this query against the warehouse, captured from when the cache was first filled. The difference is the savings.

Where to see the headers:

• DBeaver shows them in the session log directly — easiest place outside the App. See the DBeaver recipe.
• Python connectors expose them on the cursor session. See the Python recipe for the exact attribute name.
• Tableau, Power BI, Excel hide HTTP details from their UIs. Use the App's traffic page (above) for those.

For the full reference of every X-Airbrx-* header — what each one means and when it appears — see Response headers.

If something doesn't add up

• You see BYPASS instead of HIT on a re-run. The query didn't match the cache rule. Check that the statement is a SELECT (the rule from step 5 only matches SELECTs) and that the rule is enabled.
• You see MISS on every run. The cache key includes elements that vary between runs — most often userId if the BI tool reconnects as a different user each time. Look at X-Airbrx-Cache-Key and confirm the value is identical between runs.
• The header isn't there at all. The tool is hiding it. Switch to DBeaver or check the App's traffic page; both surface everything.

You're done. What's next?

That's the first hour. The Gateway is in front of your warehouse, a rule is matching real traffic, and you can see the cache working in response headers. From here:

• Add more rules. The rules workshop has more shapes you can match on — tables, schemas, statement patterns, parameter values — and more actions, including DML rules that invalidate cached reads when data changes. Start with Rules as the differentiator.
• Wire up the rest of your BI tools. Each one is a repeat of step 4. The connection recipes cover Tableau, Power BI, DBeaver, dbt, and Python out of the box.
• Watch the math. The dashboard's cache hit rate and bytes-saved tiles tell you how much warehouse compute you're avoiding as your rules cover more of your real traffic.