Thirteen cards, in the order they appear on the page and in its jump bar. The forms are server-rendered and post normally, so everything here except the beacon status and the job buttons works with scripting switched off.
Every state-changing request carries a token
Nothing on this page happens on a plain link, and a failure of that check is never softened to make a flow work.
01 · Getting it running
| Card | What it is for |
|---|---|
| Finish setting up | Setup writes the configuration. It does not start the ingest daemon and it cannot add the beacon to your site — both are done here, once, by hand. The card carries the exact command and reports whether ingestion is actually running, read from the status document the tailer writes about itself. It cannot see whether the units are enabled at boot, because Loghound executes no processes. |
| Running it | Everything Loghound put on this machine, and how to inspect, stop or remove it. The commands are copyable. |
| System check | What this installation needs from the machine, re-checked every time you open the page — with the exact fix for anything failing, written for the user PHP is really running as. Same screen as the installer’s first one. |
02 · What is collected
| Card | What it is for |
|---|---|
| Log sources | The files being read, where each format came from, and the mapping. Confirming a source and removing one are plain forms and work without scripting; rescanning is a job, because discovery walks the whole Apache and nginx configuration tree following every include and then tails and grades up to twenty files — exactly the shape of work that must not run inside one request. Log sources has the detail. |
| Solr connection | The account email, the region, whether the API key is set (never its value), both index names and the query timeout. It also carries the form for changing the account credentials and for switching to a different index pair, and the equivalent shell command for a headless install. A configuration still on the removed bring-your-own-Solr mode is refused here loudly, at the top of the card. Index schema. A block reporting whether each live index still declares every field this release writes, when it was last checked, and the command to check or fix it — the same verdict bin/loghound-schema produces, read from the file that command writes, so running it on the shell updates what the browser shows. Why that matters after an upgrade. |
| Beacon | The snippet to paste, built with your own URL and a cache-busting version taken from the beacon file’s modification time. It also renders the full option table with a Stored column filled in from your configuration — which is the only place that question can be answered concretely. This is the one card that fetches anything: a beacon-coverage check, after the page has painted. |
03 · What is kept
| Card | What it is for |
|---|---|
| Privacy | Neither installer asks about these, so this card is where both are set: how addresses are stored — full, truncated or hashed with a daily-rotating salt, each with what it costs in detection — and the age limit in days, plus whether to keep the tiny daily rollup documents indefinitely. A new installation keeps the full address and deletes after ninety days. Note the wording on the age field: zero means no age limit, not “retention off” — the disk rule on the next card is separate and keeps working. Privacy is the long version. |
| Maintenance “How much data you keep” | The card that answers the actual question, by putting the two retention rules side by side and saying which one is currently deciding. By size — when an index reaches its high-water share of the plan disk quota the oldest data is deleted back down to the target, done by the ingest daemon before it writes, so the index never reaches the quota. By age — hits older than the configured number of days, however small the index is. Plus what happens to daily rollups, the current disk figures for both indexes, and a preview job inside the card that counts what would go. Both previews only count; the panel never deletes — that is the retention command’s job, and it is deliberately the only thing in the product allowed to issue a deletion. |
| Scoring weights | Points added when a rule fires. Saving bumps the rule version, so sessions scored under the old weights stay identifiable — and existing documents are not rescored. The number inputs cap at a hundred and the fleet floor is not exposed here; tuning says what to do about that. |
04 · Access and appearance
| Card | What it is for |
|---|---|
| Sign-in | Switch between the browser’s own password prompt and Loghound’s own sign-in page; it applies to the next request and does not touch your username or password, which are changed further down the same card. Also: how many browsers are currently staying signed in, and a control to sign all of them out. Signing in. |
| Two-factor | On or off, with the enrollment flow, the recovery codes and the controls to disable or reissue — each of which costs a current code, never just being signed in. |
| Display | The timezone timestamps are rendered in. They are always shown as mm/dd/yyyy hh:mm:ss; Solr stores everything in UTC and this only changes the display. |
| Reinstall | Resets this machine and walks you back through setup without deleting a single document. Its own page: starting over. |
No secret is ever rendered
Not the API key, the beacon signing key, the address salt or the password — and not into a hidden field, a URL, a job payload, a log line or an error message. Where it matters that one is set, the card says “set” or “missing”.