GuidesTutorial

Trust Page

Publish a secret-safe customer report backed by real checks and uptime 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

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 Uptime Monitoring 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 Issues to own, resolve, and verify incidents that would otherwise show on the public timeline.