title: "Status pages" description: "Public status pages backed by your BoxWatch monitors. Share uptime with customers, post incidents, build trust." last_updated: "2026-05-24"

Status pages Pro+

Public status pages backed by your BoxWatch monitors. Pick the servers you want to expose, give the page a slug, and BoxWatch publishes a live status site at https://boxwatch.app/status/<slug>. Manual incidents go alongside the live data so customers see both the metric and your narrative.

Create a page

1. Go to Dashboard → Status Pages → New page.
2. Fill in:
   • Slug — lowercase letters, numbers, and hyphens. This becomes part of the URL. Must be unique across all of BoxWatch.
   • Name — shown as the page title (e.g. "Acme Corp Status").
   • Description — optional one-liner under the title.
   • Logo URL — optional. Linked from the page header. Use a CDN-hosted PNG/SVG.
   • Servers — which servers to display. Each picked server appears as a row with current status and recent history.
   • Theme — dark (default) or light.
3. Click Create. The page is live immediately.

The URL is https://boxwatch.app/status/<slug>.

What customers see

Each monitored server gets a row showing:

• Current status (operational / degraded / down) derived from the last received metrics.
• A rolling history bar — green/amber/red blocks for the last N hours.
• Hostname (or a friendly name, depending on what you've named the server).

Active incidents appear above the server list with title, current status (investigating, identified, monitoring, resolved), severity, and a chronological list of updates.

There's no per-server detail — the page is intentionally simple. Customers see the same thing your support team sees during an outage, minus the internal metrics.

Incidents

Post an incident at Dashboard → Status Pages → <your page> → New incident. Fields:

• Title — short headline ("API latency elevated in us-east").
• Status — investigating, identified, monitoring, or resolved. Starts at investigating.
• Severity — minor, major, or critical.
• Message — the initial update. Markdown isn't rendered; treat it as plain text.
• Affected servers — optional array. Tags the incident with the rows it relates to.

Update an incident by posting additional updates. Each update can change the status; setting it to resolved stamps resolved_at automatically.

# Add an update to an existing incident
curl -X POST https://api.boxwatch.app/status-pages/incidents/INCIDENT_ID/updates \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"status": "monitoring", "message": "Latency back to baseline. Watching for recurrence."}'

Custom domain Pro+

Status pages can be served on your own domain. In the database the column is custom_domain — wire it through DNS:

1. Add a CNAME record pointing status.yourdomain.com to boxwatch.app.
2. In the status page settings, set the custom domain to status.yourdomain.com and save.
3. TLS provisioning is automatic via Let's Encrypt; expect a few minutes.

Theming

Two themes today: dark (default) and light. The logo and the title color follow the theme. Deeper branding (custom colors, fonts, CSS overrides) isn't shipped — open a feature request if you need it.

Plan limits

Hobby plans can't create status pages — the API returns 403 with upgrade_required: true.

API

Public read endpoints for the rendered page itself are served from boxwatch.app/status/<slug> and require no auth.

(API reference pages are coming soon — see /docs/api for the overview.)

Use cases

• Public uptime dashboard for SaaS customers — one CNAME, no maintenance.
• Post-incident transparency — incident history stays attached to the page, with timestamps for every status update.
• Vendor monitoring you publish — point status-page servers at your synthetic uptime checks and show external dependencies (Stripe, AWS, etc.) alongside your own.

See also

• Server metrics — what drives the status of each row
• Uptime checks — for synthetic monitors you can include
• Alerts overview — internal alerting alongside public status