Dashboard · Configuration
Health
Every ingest answer counted, and the request log behind it.
Whether the data is actually arriving. The first screen to open when a visit is missing.
The counters#
Every answer ingest gave, counted per minute, per endpoint, per outcome:
| Outcome | Means |
|---|---|
ok | Accepted and recorded |
bad-key / bad-secret | Wrong or missing key |
origin-refused | The origin is not on the site's list |
malformed | The body would not parse |
rate-limited | Over the allowed rate |
error | A failure on our side |
Refusals that named no known site are shown as "not attributable", not as zero for some site. A request carrying a key that does not exist belongs to nobody.
The request log#
Below the chart is one row per request: when, endpoint, outcome, status, duration, origin, user agent, address.
Two limits are stated on the screen rather than hidden:
- Rows are kept 7 days, against the counters' 35. The screen says how far back it still has rows.
- The write buffer has a cap. Under load it drops rows rather than growing, and the number dropped is shown, an hour that is quiet because rows were lost must not look like an hour with no traffic.
The counters stay the authority; the log is the detail behind them.
Only requests that named a site#
Only requests that named a known site are ever served, so the log's scope is exactly the counters'. Filtering on an outcome or a site your workspace may not see is refused, not answered with an empty page, an empty page reads as "this never happened".
Diagnosis order#
- Any
okat all? Then data is arriving and the problem is workspace scope. - Any
origin-refused? Add your origin to the site. - Any
bad-key? Checkdata-site-keyis thepk_key andx-api-keyis thesk_one. - Nothing at all? The SDK never ran: check the browser console and ad blockers.