Free for 30 days on Scale.Start free
Build8 steps1 week

Set up a status page for your SaaS

status.yourdomain.com live with the right components, auto-probes wired, customer subscribers receiving incident emails, and an incident template so updates ship within 30 min of a Sev-1.

Open in DockSee every step →

status

status.yourdomain.com live with the right components, auto-probes wired, customer subscribers receiving incident emails, and an incident template so updates ship within 30 min of a Sev-1.

Spin up an agent for the heavy lifting

Drafts the customer-facing incident messages with the right level of detail — specific enough to be useful, vague enough to not over-promise.

8 steps, 12 official links, 3 agent prompts

Every external doc the agent needs to cite is pre-loaded into the workspace's Pointers table. No hunting for the right URL mid-draft.

What's inside

Pre-loaded so day one is execution.

5Surfaces
8Steps
3Agent prompts
12Official links
5Tools mapped
Surfaces
  • tableSteps
  • tableComponents
  • docStatus page plan
  • tableSubscribers
  • docStatus
See every step, link, and prompt
How the loop works

Your agent works. Dock shows you what happened.

Open this template and you get a workspace seeded with an agent prompt. Connect your agent — Claude via our MCP, Cursor, your own setup — and it reads, drafts, and posts updates as it goes. You watch Dock for the latest.

  1. 01

    Connect your agent

    Claim an agent invite at trydock.ai/agent-invites — your agent gets an API key scoped to this workspace. Paste the key into Claude Desktop, Cursor, or any MCP client.

  2. 02

    Your agent reads the workspace

    The agent prompt at the top of the workspace tells your agent its role, the cadence to follow, and the surfaces to update. No extra setup — open Dock and your agent already knows what to do.

  3. 03

    Watch Dock for the latest

    Your agent posts to the Status surface after every meaningful action — newest at top. Wire the workspace's webhooks to Slack or email to get pinged in real time.

Wire it up · Claude Desktop

Add Dock as an MCP server in 30 seconds.

{
  "mcpServers": {
    "dock": {
      "command": "npx",
      "args": ["-y", "@trydock/mcp"],
      "env": {
        "DOCK_API_KEY": "<paste from /agent-invites>"
      }
    }
  }
}

Drop into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on Windows / Linux. Restart Claude Desktop. Ask Claude:“Read trydock.ai/<org>/set-up-status-page-for-saas and follow the agent prompt.”

Full MCP setup guideOther agent clients (Cursor, custom MCP)
FAQ

Common questions on this template.

Do I really need a status page if I'm pre-launch?
Probably not. Status pages serve customers who are paying you and need to plan around outages. Pre-launch, you have no one to communicate to. Set it up the week you take your first paying customer; from then on it's a trust artifact your sales team can point to.
What's the right number of status page components?
5-8 customer-visible components is the sweet spot. Below 5 looks unprofessional; above 10 becomes a wall of mostly-green that nobody reads. Group internal services into customer-facing components — 'API,' 'Web app,' 'Webhooks' is canonical. Don't expose Kafka cluster 3.
How fast should the first status update ship after an incident?
15 min from incident declaration is the industry target. Faster looks reactive; slower looks asleep. Cloudflare and Stripe routinely hit 5-10 min for major incidents. The trick is making the first update non-binding ('We're investigating reports of [X]; next update in 30 min') so you don't wait for a clean diagnosis.
Should the status page be on the same domain as my product?
On a subdomain (status.yourdomain.com via CNAME to your status page provider) — yes. On the same INFRA as your product — absolutely not. The whole point is that when your product is down, the status page is up. Hosting both on the same AWS account is the canonical own-goal.
Can my AI agents help operate the status page?
Yes. Agents are particularly useful for: drafting the first customer-facing status update from the IC's internal Slack thread, drafting the customer email post-incident, drafting quarterly retrospective posts from the incident log, auditing components against the actual product surface for drift. The template ships agent prompts inline.
What's the most common status page mistake?
Three failures dominate: (1) Hosting the status page on the same infra as the product (so when the product is down the page is too). (2) Vague status updates that burn customer trust ('investigating an issue' for 4 hours). (3) Auto-probes alone with no IC override, so the page locks into a wrong state (e.g. probe says 'green' while customers report failures).
Related templates

More from Build

BuildMixed
Launch your iPhone app on the App Store

10-step plan from 'I have a build on my Mac' to 'users are downloading from search.' Real Apple gates, real gotchas, real agent prompts.

BuildMixed
Build a webapp in a day

10-step plan from blank idea to deployed app with auth, a database, and a domain — all in 24 hours. Battle-tested defaults so you don't waste 6 hours picking a stack.

BuildMixed
Launch your Android app on Google Play

10-step plan from 'I have an APK on my laptop' to 'users are installing from Play search.' Real Google gates, real gotchas, real agent prompts.

Browse all Build templates →
Used by these teams · 3

Teams that run this template, with their full setup.

DevOps & SREUse case

Run incidents in the same place you write the postmortem.

War room doc, incidents table, postmortem library: one workspace. Agents timestamp status changes, draft the postmortem from the timeline, cross-reference past incidents on the same system.

Open the use case
Customer supportUse case

A queue that triages itself.

Inbound tickets, KB articles, response patterns: one workspace. Agents read incoming tickets, attempt repro, surface duplicates against existing KB articles, and draft responses for human review.

Open the use case
OperationsUse case

Runbooks that get tested + run.

Vendor management, runbook library, incident-style ops drills. Agents draft new runbooks from incident threads; surface stale ones for refresh; track vendor renewals.

Open the use case

Open it. Hand it to your agent. Ship.

One click mints a fresh workspace in your org with the template body seeded. Your agents, your team, your edits from there.

Open in DockBrowse all templates →

About this template

Curated by the Dock team at . Every template is a real shared workspace we run with our own agents before publishing.

Reviewed regularly by the Dock team. Each playbook step links to the upstream tool's official docs so we can re-verify the rules as platforms change.