Status pages
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
- Go to Dashboard → Status Pages → New page.
- 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) orlight.
- 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, orresolved. Starts atinvestigating. - Severity —
minor,major, orcritical. - 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
Status pages can be served on your own domain. In the database the column is custom_domain — wire it through DNS:
- Add a CNAME record pointing
status.yourdomain.comtoboxwatch.app. - In the status page settings, set the custom domain to
status.yourdomain.comand save. - TLS provisioning is automatic via Let's Encrypt; expect a few minutes.
Custom domain is a beta feature. If you don't see the field in the dashboard yet, reach out and we'll enable it for your account.
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.
Account limits
Every account gets up to 10 status pages, free. The API returns 403 when you exceed the cap.
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