Feature · Status pages

Example FTStatus customer status page

Preview how FTStatus presents service health, incidents, maintenance notices, subscribers, and customer-safe updates without depending on a live customer page.

status.ftstatus.com
Live status board99.98% uptime
Marketing siteftstatus.com182ms
API gatewayapi.ftstatus.com96ms
Checkout servicedegraded · recovering+413ms
Auth & sessionsauth.ftstatus.com54ms
Background jobsworker poolOK
HTTP · DNS · TCP
live checks
1 min
Team cadence
Real
uptime history
Public
status page
  • Show customer-facing components such as website, portal, API, and notifications.

  • Explain incidents and planned work in plain language.

  • Keep internal probes, hosts, server paths, and provider notes private.

Status pages

Operational summary

A public status page should answer the customer question first: is the service operating normally, degraded, under maintenance, or recovering?

Monitor

Component structure

Group monitors into readable services such as Main website, Client portal, API, Mail delivery, and Support desk instead of exposing raw infrastructure.

Response time · 24h

182 ms
AMSIADLHR

Alerting

Update workflow

Incident and maintenance updates should move through investigating, identified, monitoring, and resolved states with clear timestamps.

Looks right either way

Light or dark, your status page stays on-brand.

Match what your customers expect with a clean light or dark public page — same components, same clarity.

AAcme CloudAll systems operational
WebsiteOperational
APIOperational
PaymentsOperational
Email deliveryOperational

Last 90 days · 99.98% uptime

Safe for public status pages

  • Website and application availability
  • API health endpoint status
  • DNS and SSL issues affecting customer access
  • Maintenance windows and incident timelines
  • High-level region coverage

Internal operations only

  • SSH, admin panels, databases, queues, and backups
  • Server names, origin IPs, provider IDs, and ports
  • Firewall rules, file paths, and secret-related config
  • Primary or backup probe node details
  • Customer-specific private control panels

Setup workflow

From first check to customer-ready status.

1

Create customer-facing service components.

2

Attach confirmed monitors to each component.

3

Publish maintenance and incident updates only after the public wording is approved.

Set up monitoring your customers can trust.

Start free with the checks that matter — sites, APIs, DNS, and hosted services — then add status pages and alert routing as you grow. No credit card, and local Faciotech support when you need it.

Start free