DRAFT - FOR REVIEW
Viewee Public Status Page Plan
Hosted status page and incident communications | Version 0.1 | 16 September 2026
Start with Better Stack's free tier. It gives Viewee one integrated status page, 10 monitors/heartbeats, email and Slack alerts, up to 1,000 status-page subscribers and a custom subdomain according to the current official pricing page. That is enough for the marketing site, app and API, leaves room for SSL/heartbeat checks, and keeps monitoring and public incident updates in one tool.
Use the provider-hosted URL until DNS is configured, then publish at status.viewee.co.uk. Keep the status page independent of Viewee's own application hosting and marketing site so it remains available during a Viewee outage.
Better Stack vs Instatus
| Criterion | Better Stack free | Instatus Starter free |
|---|---|---|
| Monitors | 10 monitors and heartbeats | 15 monitors; 2-minute checks |
| Status pages | 1 included | 1 public page |
| Custom domain | Official pricing lists custom sub-domain among status-page features | Not on Starter; Pro is required |
| Subscribers | 1,000 included | 200 |
| Team/on-call fit | Integrated uptime, alerts, incident timeline and on-call; paid responder features may apply as the team grows | 5 team members, 2 on-call members and 2 escalation policies on free |
| Strength | Best path to status.viewee.co.uk without immediately paying, subject to confirming setup at launch | More free monitors and generous small-team incident features |
| Constraint | Free tier is described as for personal projects; confirm Viewee's commercial eligibility before relying on it | No custom domain on free, so status.viewee.co.uk needs Pro ($20/month or $15/month annually at current pricing) |
Decision: Better Stack is the better first fit because the requested branded subdomain and subscriber headroom matter more than five extra checks. If Better Stack confirms that its free tier cannot be used for Viewee's commercial service, use Instatus Starter on its hosted URL for launch, then move to Instatus Pro or another paid plan when branded DNS is required.
Public components
| Component | What it means | Check |
|---|---|---|
| Viewee website | Public marketing site and contact/demo route | HTTPS check from at least two regions; validate expected page text, not only HTTP 200. |
| Viewee app | Login and primary customer web experience | Public health/login check with no customer data; later add a safe synthetic sign-in if supported. |
| Viewee API | Production API used by the app and integrations | Dedicated /health or /ready endpoint covering critical dependencies without exposing versions, secrets or data. |
Add SSL-certificate expiry checks and a background-job heartbeat when those services exist. Do not put admin panels, database endpoints, IP addresses, supplier secrets or security details on the public page.
Status definitions
Operational: available and performing normally.
Degraded performance: slow or intermittent but usable.
Partial outage: one component or material function unavailable.
Major outage: most customers cannot use the core service.
Maintenance: planned work with possible impact.
Set incidents manually after validating an alert. Avoid publishing every single-region transient failure. For a two-person team, alert both founders for confirmed app/API failures during working hours; use best-efforts alerts out of hours until Viewee funds a real on-call rota.
Launch plan
Create the hosted page and three public components.
Create monitors with two consecutive failures before paging where supported; check every 1-2 minutes.
Send alerts to both founders' operational addresses; test failure and recovery.
Write an incident owner checklist: verify, assign severity, publish, update, resolve, review.
Configure DNS CNAME for status.viewee.co.uk exactly as the provider instructs. Confirm TLS and loading from outside Viewee's network.
Link the page from app footer, website footer, support SLA and customer onboarding.
Run a tabletop incident and a real monitor test before announcing the page.
Incident communications principles
Say what users experience, which components are affected and when the next update will arrive.
Use timestamps in UK time and UTC where customers may be distributed.
Do not speculate about cause, blame a supplier or disclose exploitable details.
For a possible security or personal-data incident, publish service impact only until the incident lead approves further detail. Use private contractual/regulatory channels for protected information.
Post a final summary and link to a post-incident review when proportionate.
Templates
Investigating
[Component] - investigating [degraded performance/availability]
We are investigating reports that [plain-language user impact]. The issue began at approximately [time]. [Components] are affected. We will post another update by [time], or sooner if the position changes.
Identified
[Component] - issue identified
We have identified the issue affecting [user impact] and are applying a fix. [Safe workaround, if any]. We will update again by [time].
Monitoring
[Component] - service restored, monitoring
Service was restored at [time]. We are monitoring recovery and validating [affected function]. Some users may need to [safe action]. We will confirm resolution after the service remains stable.
Resolved
[Component] - resolved
The incident affecting [user impact] was resolved at [time]. The incident ran from approximately [start] to [end]. [One-sentence safe cause or "We are reviewing the cause"]. We will record follow-up actions and share more detail where appropriate.
Planned maintenance
Planned maintenance - [component]
We will carry out maintenance on [date] from [start] to [end] UK time. During this window, users may experience [expected impact]. No action is required unless stated. We will confirm when maintenance is complete.
Ownership and review
One founder is incident commander and the other handles customer communications. Review subscriber growth, false alerts, detection time, publication time and incidents quarterly. Reassess the vendor when Viewee needs contractual uptime, private/customer-specific pages, more responders, SSO or longer evidence retention.