---
id: "7.5"
title: "Dashboards"
dept: data-and-analytics
status: needs-you
owner: Param
branded: false
last_verified: "2026-10-26"
sources:
  - "brew/docs/production.md:112-115"
  - "brew/alerts.js:1-13"
  - "brew/server.js:657-666, 810-824"
  - "brew/brief-status.js:1-6"
  - "brew/db/status.mjs:16"
  - "memory brew-prod-backend, brew-access-rules, brew-apify-watch"
  - "handbook content/data-and-analytics/metric-definitions.md, content/data-and-analytics/tracking-plan.md"
---

# Dashboards

## Answer

No dashboard of company numbers exists; today we read health from Cloud Monitoring, alert emails and a few admin routes, and this page proposes three views, who reads each and when, once the events in the tracking plan exist.

## Today

| View | Shows | Who reads it | Source |
|---|---|---|---|
| Cloud Monitoring | Uptime of `/`, `/healthz/ready`, `/api/config`; 11 alert conditions | param@ and hello@ by email | [src: brew/docs/production.md:112-115] |
| App alerts | Vertex billing and quota, AI pause, treg low, 5xx rate, Sloosh down, once a day each | hello@ | [src: brew/alerts.js:1-13] |
| `GET /api/admin/visitors` | Which emails opened which brand, with access kind | Root admin | [src: brew/server.js:657-666, 817-819] [src: memory brew-access-rules] |
| `GET /api/admin/sessions` | Sign ins of one email; sign out everywhere | Root admin | [src: brew/server.js:810-814] |
| `GET /api/admin/sources` | Source health for treg and Apify | Staff | [src: brew/server.js:824] [src: memory brew-apify-watch] |
| `brew-ops` job | Arata's connection states and table sizes | Whoever runs it | [src: brew/db/status.mjs:16] [src: memory brew-prod-backend] |
| Brief status pill | Briefs sent to our team and where each stands | Staff | [src: brew/brief-status.js:1-6] |

No view shows active brands, hand-offs, activation or cost per brand. [src: handbook content/data-and-analytics/metric-definitions.md]

## Tomorrow

| View | Shows | Reader | When | Version | Tag |
|---|---|---|---|---|---|
| Weekly partner view | Per partner: active, cards hearted, made, handed off, facts corrected, last sign in | Param, Sai, Arvind | Monday team call | v1 | New, proposed |
| Weekly company view | North star, activation, return, taste, making, trust, cost per active brand | Param | Monday | v1 | New, proposed |
| Health view | Uptime, errors, slow requests, connector reads failing, stale connections, spend against caps | Engineering | Daily | v1 | New, proposed |
| Posting view | Posts approved, scheduled, published, failed | Team | Weekly | v2 | New |
| Results view | Measured share, grade mix, results by family | Team and the brand's own view | Weekly | v3 | New |
| Rules view | Runs, undos, spend inside limits | Team and the brand | Daily | v4 | New |

### Proposed build

- A staff only page in the product, `/ops/weekly`, reading the `events`, `access_log` and `counters` tables, no third party tool.
- Numbers only as defined in metric definitions; every tile says its definition on hover.
- Staff and demo activity filtered out by default.

## How we do it

1. Every tile reads one defined number; a new tile means a new row in metric definitions first.
2. Until the page exists, Param reads the visitors list and the brief pill before the Monday call.
3. Run the ops job for table sizes and Arata's connections:

```bash
gcloud run jobs execute brew-ops --region=asia-south1 --wait
```

## Numbers

| Metric | Definition | Where measured | Status |
|---|---|---|---|
| Views live | Proposed views that exist | This page | 0 of 3 for v1 |
| Weekly view read | Mondays the view was opened before the call | `access_log` on `/ops/weekly` | Proposed |

## Open

1. **Build the weekly views in the product or in a tool?** Proposal: a small staff page in the product, so data never leaves our database.
2. **Who owns the Monday read?** Proposal: Sai prepares, Param decides.
3. **Show partners their own view?** Proposal: not in v1; in v3 the brand gets its results view.