Statuspage provides multi-tenant service-status management in Tools while the public status site remains an independently deployable frontend.
The public client is the standalone Tornevall/tornevall-networks-tools-statuspage React application available at /status. Tools serves the production build of that client, while ToolsAPI continues to own status data, permissions and management.
The public application URL stays /status, while the client's static resources are delivered from public/status-client. There must not be a physical public/status directory. This keeps /status and /status/{slug} as stable Laravel application routes without changing bookmarks, tenant URLs or the public API contract.
/statuspage and /statuspage/{slug} remain compatibility redirects to /status and /status/{slug}. The default public page is /status. Tenant pages use /status/{slug} and the same public client selects the requested validated slug.
The standalone client reads published status data from the unversioned public endpoint:
GET /api/statuspage/{slug}
Only pages explicitly marked public with an active publication timestamp are returned. The response contains public page status, components, incidents, published incident updates and safe event fields. Internal incident text, unpublished updates, audit records and internal event metadata are never returned.
Each public component can also include a 90-day daily history and availability summaries for the latest 24 hours and 30 days. A day with no recorded disturbance is operational by default. Manual component and page status changes are recorded as component/page-wide observations; those observations and incidents change the affected day's status, while a resolved disturbance stays visible in that day's history. The current public component state is derived from the latest observations and active incidents, so a recorded recovery can return the live state to operational without erasing the earlier disturbance from history. The public page-level state likewise follows the latest page-wide observation plus active incidents and component state, including pages without components. For legacy rows that predate observation history, the first recorded status transition - manual or automated - preserves the prior persisted state as a baseline before recording the new state, so a recovery does not erase the preceding outage interval.
For the seeded ToolsAPI page, successful deployment health verification records an operational observation. A deployment whose production HTTP health verification fails records an outage observation when the runtime can persist it. A later successful deployment records recovery. These observations use the same public history contract as manual component and incident state and do not expose internal event metadata.
Tools APIs use canonical unversioned URLs. Do not add URL namespaces such as /v1 or /v2.
The /services catalogue includes Statuspage with a direct Public status link. Signed-in users also get Manage my Statuspages. Administrators additionally get Configure Tools status, which opens the seeded ToolsAPI page directly, plus Manage all Statuspages for the global administration index.
Signed-in users manage status pages owned by their account at /me/statuspage. The owner screen separates page creation from the existing-page list and provides direct links to public pages when published.
Owners can create, edit, publish or unpublish pages, manage components, change component state, open incidents and add public or internal incident updates. Ownership is enforced by the backend for every resource action.
Administrators manage all Statuspage resources at /admin/statuspage. The seeded ToolsAPI status page can be opened directly at /admin/statuspage/tools, and the administration index exposes a dedicated Configure Tools status shortcut together with a direct link to /status/tools.
The administration interface uses the same structured page, component and incident editor as the owner surface and also allows global ownership management.
Administrator status controls use dropdowns instead of free text. Page and component status choices are operational, degraded, partial_outage, major_outage, maintenance and unknown. Incident lifecycle choices are investigating, identified, monitoring, resolved, scheduled and unknown; incident impact choices are minor, major, critical, maintenance and unknown. New administrator values are restricted to these lists; an already stored legacy/custom value can remain unchanged until an administrator selects a canonical choice. Existing owner-surface behavior remains unchanged.
These routes require explicit backend administrator authorization; the URL prefix and GUI visibility are not authorization by themselves.
Meaningful page, component, incident and automated health observations are recorded in the dedicated Statuspage audit store with actor or process, action, result, affected resource and correlation ID. Audit context is bounded and must not contain credentials or secrets.
Unexpected Statuspage operation failures are reported independently through the always-on Tools operational diagnostics path to #toolsapi, with safe service/action/result/error/correlation context. Audit settings do not disable operational failure reporting.
For the seeded Tools status page, configured operational errors can also update a matching public component automatically. The mapping, automatic-creation policy, default severity and matching rules are defined in config/statuspage.php. A configured component may be created on first use when it does not already exist; if an existing component has the configured display name, Tools adopts it instead of creating a duplicate. Matching uses an internal stable component key so later display-name changes do not break health routing. Repeated identical failures are deduplicated before new history/audit rows are written, and internal fingerprints, provider codes and request references are not exposed by the public API.
Suggestions and Job Search are configured as automatic components. Public/admin Suggestions route failures update the Suggestions component, while Job Search web/API/service failures update Job Search; both default to degraded. A matching component may be auto-created on the first production failure when automatic creation is enabled. OpenAI is also configured as an automatic component; critical provider-account failures such as exhausted credits/quota, invalid provider credentials or deactivated project/account access mark the OpenAI component major_outage. Ordinary non-critical OpenAI operational failures use degraded. These automatic health observations are separate from public incident posts, which remain an explicit operator action.
After a successful ToolsAPI deploy, components with a configured health key that are currently non-operational because of the operational-error bridge can be re-checked with an explicit deterministic recovery probe. This includes an existing same-name component that the bridge adopted instead of duplicating. Suggestions probes /suggestions and Job Search probes /job-search, but only when that same route was recorded on the latest operational-error event and the failed request was anonymous, so the anonymous recovery request reproduces the relevant execution context. Authenticated or unknown request contexts, plus background/service failures without a matching failed route, are not cleared by a page probe. Bridge failures and successful recovery transitions also serialize on the same component lock so a fresh failure cannot be hidden by a concurrent recovery. Only an expected successful response records a component-specific operational recovery observation. Failed probes leave the previous state intact. OpenAI has no deploy recovery probe because a healthy application deploy does not prove that the external provider/account has recovered.
An explicit operator correction can also append a recovery observation when a service is known to have recovered but Statuspage itself failed to record that transition. Such a correction only applies while the latest component event is still the matching automated bridge failure; a newer manual, provider or operator observation is never overwritten. Historical faults remain visible through events and resolved incidents even after the current component state returns to operational.
The database migration seeds ToolsAPI as ordinary published Statuspage data using slug tools. It uses the same data model and public API contract as every other status page; the public frontend simply uses tools as its default page.