Trust Center
Publish a customer-facing, secret-safe trust report backed by real PreFlight evidence.
Guides
Trust Center
When a prospect, auditor, or enterprise buyer asks "how do I know your integrations actually work?", dashboard screenshots are not an answer. The Trust Center turns a project's real PreFlight evidence into a clean, shareable, customer-facing page — without exposing anything sensitive.
Trust Center reports are generated from stored probe rows, uptime samples, and incident history. They prove that checks pass; they never reveal how providers are wired or what credentials are stored.
What it publishes
A Trust Center page is built from persisted evidence at /dashboard/projects/:id/trust-center:
| Surface | What it shows |
|---|---|
| Overall status | operational, degraded, major_outage, or maintenance derived from probe results |
| Service statuses | Per-integration health with optional response times |
| Uptime | Seven-day percentage and daily breakdown when enabled |
| Incidents | Customer-visible incident timeline when showIncidents is on |
| Maintenance windows | Scheduled maintenance with start and end times |
| Custom services | Additional status rows you define for non-probed dependencies |
Public pages are served at /trust/:slug using the slug configured on the project.
What it must never expose
The Trust Center is public-facing by design. Safety rules are strict:
- No encrypted provider credentials
- No raw webhook URLs or signing secrets
- No API keys or private provider tokens
- No internal dashboard URLs or workspace identifiers beyond the public slug
Evidence, not secrets
The report proves health posture from stored probe results. Sensitive values are redacted before rendering. If a value could help an attacker, it does not appear on the trust page.
Configuration options
| Setting | Purpose |
|---|---|
| Title / description | Customer-facing headline and summary |
| Slug | Public URL path at /trust/:slug |
| Show response times | Display per-service latency from recent probes |
| Show incidents | Include resolved and active customer incidents |
| Show uptime percentage | Seven-day uptime rollup |
| Theme color / logo | Brand alignment for the public page |
| Contact email / support URL | Where buyers reach your team |
Publishing a report
Open the project Trust Center tab. Navigate to
/dashboard/projects/:id/trust-center.Run a clean check first. Resolve failed probes — the report reflects the latest stored evidence, not aspirational state.
Configure visibility. Choose which surfaces (uptime, incidents, response times) appear on the public page.
Preview and publish. Review the customer-facing page, then share the public URL or an expiring export link from Exports.
Status mapping from probe results:
| Probe status | Trust Center status |
|---|---|
success | operational |
warning | degraded |
failed | major_outage |
When to use it
- A buyer's security review asks for proof of integration and uptime health.
- You want a public status-style page backed by real checks, not a hand-edited badge.
- Sales needs a current artifact instead of a stale PDF.
- Compliance questionnaires ask for third-party verification of operational controls.
Pair Trust Center with Exports for PDF/JSON artifacts and expiring share links when the recipient needs a downloadable attachment.
Keeping it accurate
Trust Center reflects the most recent stored probe rows. To keep the public page credible:
- Enable Sentinel for continuous sampling between manual checks.
- Route Alerts so your team fixes degradations before customers notice.
- Re-run checks after integration or deploy changes.
- Use Incident Command to resolve and close incidents that would otherwise show on the public timeline.