Trust surface
Public status page
status.attesto.eu gives customers, evaluators, auditors, and developers a public view of customer-facing Attesto service health. It is intentionally separate from tenant evidence storage and internal staff-only operations: it stores only public probe results and public incident metadata.
Scope
The status page answers one question: are the public Attesto services that customers depend on currently reachable and responding as expected? It is not a proofstream verifier, not a tenant audit log, and not a private operations console. Use it as a quick availability signal, then use receipts, verifier bundles, and audit reports for cryptographic evidence questions.
Monitored components
| Component | What it represents | Public endpoint class |
|---|---|---|
| Dashboard | Tenant operator panel for customer users. | Public HTTPS page. |
| Audit Portal | Auditor verification portal. | Public HTTPS page. |
| Verify API | Public verification and backend readiness endpoint. | Public health endpoint. |
| Docs Hub | Public documentation, SDK guides, and trust docs. | Public health endpoint. |
| Marketplace | Connector catalog and developer marketplace. | Public health endpoint. |
Internal staff-only surfaces are deliberately excluded from the public status component list. The public page should never disclose private diagnostics, tenant data, raw logs, provider payloads, credentials, or operational runbooks.
Status states
| State | Meaning | How to interpret it |
|---|---|---|
| Operational | The latest public probe returned the expected HTTP status. | The public service is reachable from the status monitor. |
| Partial outage | At least one monitored customer-facing service is not responding as expected. | Check the affected component and public incident list. |
| Degraded | A service is slower or partially impaired. | Retry sensitive workflows and watch latency/history. |
| Outage | A monitored service is unavailable or returning an unexpected response. | Pause dependent workflows where evidence policy requires availability. |
| Collecting | The monitor has not recorded enough probe data yet. | Wait for the next probe interval or check the public service directly. |
Uptime bars
The ticker bars show the latest 90 days per monitored component. Each day is computed from recorded public probes in the status database. Green means the recorded probes for that day were operational, yellow means degraded, red means outage, and gray means no data. The page also shows the configured history window, probe interval, and data timezone.
Latency and HTTP expectations
Every component card includes current latency, last check time, the observed HTTP status, and the expected HTTP status. Latency is the time taken by the status monitor's public request; it is useful as a customer-facing signal, but it is not a full synthetic transaction and it does not prove every tenant workflow is healthy.
Incidents
Public incidents describe customer-visible service issues and their current state. They should be concise and safe to publish. Incident text must not contain tenant identifiers, raw logs, provider payloads, private investigation notes, credentials, or internal-only remediation details.
Status API
The status service exposes the same public data as JSON at
/api/status and /v1/status. The response
includes overallStatus, generatedAt,
components, incidents, daily
history, and privacy flags confirming that
tenant data, raw logs, and provider payloads are not exposed.
Privacy boundaries
- Status data comes from public probes and a dedicated status database.
- The status service does not read the Attesto application database.
- The page does not expose tenant evidence, private logs, provider payloads, credentials, or raw traces.
- Customer evidence integrity is verified through receipts, bundles, witnesses, anchors, and offline verifier reports, not through the status page.
What to do
| Situation | Recommended customer action |
|---|---|
| All systems operational | Continue normal dashboard, verification, marketplace, and documentation workflows. |
| Verify API degraded or unavailable | Keep existing receipts and bundles; retry online verification later or use offline verifier where possible. |
| Dashboard unavailable | Avoid creating new tenant operations through the UI until the component recovers. |
| Docs unavailable | Use installed SDK help, package README files, and cached docs if already available. |
| Marketplace unavailable | Installed connectors keep their own runtime behavior; postpone browsing, purchase, or install actions. |