#FE: Log Monitoring screens (from backend Phase 13)
Frontend spec for backend Phase 13 — Log Monitoring add-on — requirements complete 2026-10-07, not built — the install channel still needs the OSS team (13.3). Rewritten by the backend the same hour to follow how OSS actually runs it, which added real detail and moved the numbering: update and remove are now 13.6 and 13.7, the activity log 13.8. V8 requirement This is V7's InsightHub, rebuilt as reports inside Central instead of a separate dashboard app on the user's server.
Add-ons page — the card
included with a plan, or bought. Lost on a downgrade
Server — install / enable the toolkit on this server, then update or remove it
Apps — every app on the server, registered automatically; no per-app switch
Application panel — the reports
Dashboard, Traffic, Errors, Bots, User Agents, Bandwidth
i18n namespaces: addons.logMonitoring.*, logMonitoring.install.*, logMonitoring.reports.*.
#A. The add-on itself
| # | Feature | Screen / control | Rules from the backend doc | Frontend notes |
|---|---|---|---|---|
| 13.1 | The add-on | Add-ons card | Included in a plan (7.26) or bought — same as V7. Taking and paying an eligible plan enables it automatically on the account. Tied to the plan: moving to a plan without it switches it off and removes it from all the user's servers, as V7 does on downgrade | The card reads Included when the plan carries it, which is the normal 7.26 behaviour — unlike White label, which reads Purchased. The removal is the part that needs care: it is not a quiet flag change, it uninstalls from every server, so the plan-change screen has to say which servers lose monitoring before the user confirms — and since 13.7 was answered on 2026-10-07, it must also say that every collected report is deleted and that turning the add-on back on starts from zero. The add-ons card needs a state for "switched off because your plan changed" that explains how to get it back, without implying the old reports come back with it |
| 13.2 | Licence | An error state, not a screen | Before every run the toolkit asks ServerAvatar's licence service "has this server bought it?", recognising the server by its IP. Central answers yes for every server on an account that has the add-on — otherwise the reports are refused with "licence required" | The refusal is the frontend's share of this. "Licence required" is not a crash and not an empty report: it means the add-on is gone or the server is not recognised, so the reports screen must say which and point at the add-ons card. And since recognition is by IP while 9.29 lets a server's IP change in Central, this is the most likely way a user meets that message — whether the licence service follows an IP change is not stated (see the open items) |
| 13.8 | Activity log | Existing activity log | Install, update and remove are recorded (as V7) — the per-app entries went with the per-app switch on 2026-10-07 | New event types for the log that already exists — nothing new to build, but each entry must name the server, since that is now the only level this add-on works at |
#B. Installing it on a server
| # | Feature | Screen / control | Rules from the backend doc | Frontend notes |
|---|---|---|---|---|
| 13.3 | Install on a server | Install Log Monitoring — a server-level action, placement undecided, see D-46 | After a server is created, the user clicks Install Log Monitoring. Central first asks OSS whether the toolkit is already there (installed, and which version). If not, the toolkit goes on the server: the program, its settings file and a new database, plus two background jobs — fetch, which reads new log lines about every 15 minutes, and prune, which deletes data older than the retention days (default 7). Central provides the program. Progress is shown until it finishes. Gap: OSS has no way to receive it today — the OSS team must add an install call, or the OSS installer must install it. Until then this step cannot be built | Missing on the OSS side, and the backend is blunt about it, so this is not plannable work yet. Three things the screen owes the user. It is a real install, not a switch — a program, a database and two jobs land on their server, so say so before the button. The "already installed?" check comes first, which means the screen has three entry states, not two: not installed · installed (with its version) · installed but older. And progress reuses the add-server install pattern (8.9) — live steps, a reason on failure, Retry — rather than a second progress screen of its own. The 15-minute fetch and 7-day retention are the two numbers users will ask about, so put them on the screen in words; whether the retention days can be changed is not stated, so nothing offers to change them |
| 13.4 | Apps become monitored | Nothing to build — there is no control | Changed again 2026-10-07: after install Central registers all apps of the server automatically (name, system user, domain, web server, SSL); apps created later through Central are added automatically; domain or SSL changes update the registration; deleted apps are removed. There is no per-app on / off — as V7, it covers every app on the server | This reverses what this page published an hour earlier. The first version of 13.4 had a per-app switch and this spec described it as "an off switch for exceptions"; the backend has now removed the switch entirely, so there is no per-app control to design at all — monitoring is a property of the server, not of an app. Two consequences worth stating: an app screen must never imply monitoring can be turned off for one app, and the only way to stop it is to remove the toolkit from the server (13.7), which stops it for everything. The automatic housekeeping is the good news — new apps, domain and SSL changes and deletions all keep themselves in step |
| 13.6 | Update | Update on the same server screen | Central updates the toolkit to a new version, then re-checks bot detection once | A plain Update with the current and available version. The bot-detection re-check is the backend's own follow-up step, so the screen should not present it as a user choice |
| 13.7 | Remove | Remove TYPE-TO-CONFIRM | Answered 2026-10-07 — same as V7: unregister all apps, stop both jobs, remove the program and delete its database with every collected statistic. Installing again starts fresh — the old history is gone. The same happens on a plan downgrade (13.1) | Now that the answer is known, this is data loss, not a disconnect — so it earns the strongest confirm in the add-on: name the server, say all collected reports are deleted, and say that reinstalling starts from zero. The earlier version of this page could not promise either way; it can now. And the harder consequence is the one the user does not initiate: a plan downgrade deletes the same data on every server, so the plan-change screen must say reports will be deleted, not merely monitoring will stop. There is nothing to download first — the backend offers no export |
#C. The reports
| # | Feature | Screen / control | Rules from the backend doc | Frontend notes |
|---|---|---|---|---|
| 13.5 | Reports | In the Application panel (Phase 10) — no item for them in the fixed app menu, see D-46 | Dashboard, Traffic, Errors, Bots, User Agents, Bandwidth — the same groups as V7, 49 reports, and some take a limit, a field or a status code. OSS keeps each answer for a short time, so re-opening is fast. If fetch has not run yet the reports show zeros, not an error — Central shows "collecting data" | Six groups and 49 reports is a section, not a tab, and it is the largest single addition to the app panel so far. Three rules keep it sane. Per-report options, not one global filter: the backend says some reports take a limit, a field or a status code, so the controls belong to the report and the state stays in the URL so a view can be shared. "Collecting data" is a first-class state — the backend went out of its way to say zeros are not an error, and the screen must match, because the first 15 minutes after an install would otherwise look broken. And the reports are read-only, so none of them needs a mutation path. OSS's short-lived cache means a refresh may legitimately return the same numbers — do not present that as stale |
| — | Where the data comes from | — | The reports come from the toolkit on the server, read through the OSS API — and the backend notes the OSS panel itself has no Log Monitoring screen; this is a Central-only add-on API | So these screens have no OSS counterpart to copy, unlike every other app screen in Phase 10. They are our own design, and the offline-panel state matters more than usual: without the panel there are no reports at all, so the group needs the same unreachable state as the rest of the app panel |
#What this phase answers
| Open item | Answer |
|---|---|
| Log Monitoring was "an add-on phase, later" on FE: Application screens, FE: Plans & subscription 7.26 and FE: Notifications & mail | It is now a written phase (13.1–13.7) V8 requirement — the third add-on to get one, after White label (Phase 12) |
| What happened to V7's InsightHub app? | Dropped. The separate InsightHub dashboard app, its domain and its domain-change flow are not in V8; the reports live in Central instead. That also retires V7's "monitoring domain change" message, which Phase 11's email map had parked for this phase |
| Is an add-on lost on a downgrade? | It depends on the add-on, and now both answers exist — White label is lifetime (12.11), Log Monitoring is removed from every server (13.1). The downgrade check (7.8) must name the second and not the first |
| What do V7 Log Monitoring owners keep? | They keep the add-on while their plan includes it, and their servers start fresh on the OSS toolkit — the old V7 agent and its database are stopped and removed first, so logs are not read twice. Past report history from V7 is not carried over, so a migrated user's reports legitimately start at zero and need the same "collecting data" message as a new install, not an error |
#Still open after this phase
| # | Question |
|---|---|
| D-46 | Where do the reports and the install action go? 13.5 puts six report groups in the Application panel, but the frontend doc's app menu order is fixed (U14.4) and has no item for them; 13.3's install / enable is a server-level action and the server menu is fixed too (U13.4). Same family as D-40, D-43 and D-45 |
| — | Does the licence follow a changed IP? 13.2 recognises a server by IP; 9.29 lets the IP change in Central. Nothing says whether monitoring keeps working, so no screen promises it Open question |
| — | |
| — | The install needs OSS work that does not exist (13.3) Missing — an install call, or installer support. The backend says plainly that until then this step cannot be built, whatever Central does |
| — | Can the user change the retention days? The default is 7 (13.3), but nothing says whether it is a setting, so no screen offers to change it Open question |
| — | What about apps created later directly in the OSS panel? 13.4 registers all existing apps at install, and apps created through Central afterwards; an app made in the panel later is still not mentioned Open question |