Skip to main content
Status pages give you a public place to communicate current component health and active incidents. Every plan can publish at least one Squasher-branded public status page. Paid plans add higher page, component, subscriber, and monitor limits; Pro and above can use a custom status domain.

​
Draft and publication safety

New status pages start as Draft. A draft is not visible to customers. Turn on Public status page only when the page identity, components, and monitor links are ready. Editing an existing page preserves its current visibility; saving a name, theme, or component change does not publish a draft by itself. Internal incident work is also private by default. To publish it manually, open the incident’s Communications view, select Declare outage, choose the public status page and affected components, and provide a public title and summary. Later public updates use a separate action. Unpublishing requires confirmation and removes the outage entry from customer view. A configured monitor publication rule can publish eligible monitor incidents after its delay. This does not make unrelated investigations, comments, evidence, or internal status changes public.

​
A typical page includes

  • Component status
  • Component groups for related services or third-party dependencies
  • Active incidents
  • Active and upcoming scheduled maintenance windows
  • Recent incident history for resolved incidents from the last 90 days
  • Live social previews that reflect the current page status and component uptime
  • Optional support or help links
  • Custom branding with accent color and headline

​
How updates stay aligned

When your monitors target the same public components, monitor results and incident changes can roll into the status page automatically. Component health is recalculated after every monitor check. In the dashboard, choose the backing monitor directly when you add or edit a component. Direct monitor links survive component renames, so a customer-facing label change does not break the health rollup. Agents and scripts can use the same backing model through the public API. Component create and update requests accept type: "monitor" with monitorId for Squasher-backed health, type: "static" with an HTTP(S) externalStatusUrl for third-party dependencies you do not probe directly, or type: "group" for parent rows. Child components set parentComponentId to the group id, and can clear it with parentComponentId: null. The link-monitor / unlink-monitor endpoints still set or clear a component’s direct backing monitor without depending on component names. Public pages render from the latest Squasher status data and use a short cache. Most dashboard edits appear within about 30 seconds, while monitor state changes and public incident updates are invalidated immediately and usually appear within a few seconds. When you share a public status page, Squasher renders the Open Graph preview from the same current page health, active incidents, and component uptime used by the page itself. Resolved incidents stay in the public history for 90 days. Active incidents remain visible until they are resolved, even when they were first published more than 90 days ago. Maintenance windows with scheduled or active status appear on the public page until the window ends. This gives customers one place to see both current outages and planned work.

​
Component order

Drag components in the status page settings to choose the order customers see on the public page. New components appear at the end until you move them. When components are grouped, the public page nests child components under their group and shows the group’s customer-facing health from the most severe child state.

​
Custom domains

You can serve your status page on your own subdomain like status.example.com. See Custom domains for status pages for setup instructions. Every status page also gets a free managed subdomain at {slug}.status.squasher.ai that works immediately. Custom status domains are available on Pro and higher plans. Free pages use the managed Squasher status subdomain.

​
Theming

You can customize the appearance of your status page:
  • Accent color — used for the header dot, links, and support button
  • Headline — a short message shown below the page title
  • Support URL — a link shown in the page header for customer support
Custom CSS is available on Scale plans. Lower tiers can still set the accent color, headline, and support URL.

​
Managing subscribers

Use the dashboard for normal subscriber review. For cleanup and automation, the public API and CLI can list, inspect, or delete subscribers on a status page:
Subscriber records include the delivery channel and any component scope selected for that status page. Email subscribers choose all components or selected components when they confirm the subscription; subscribers without component scope receive updates for the whole page. Webhook subscribers are activated only after Squasher sends a one-time verification ping and the receiver echoes the provided secret; outage updates are then delivered as Standard Webhooks-signed JSON payloads.

​
Best practices

  • Keep component names clear and customer-facing.
  • Validate monitor mappings before you share the page publicly.
  • Use a custom domain so customers see your brand, not a Squasher URL.
  • Set a support URL so customers know where to go if they need help.

​
Agent handoff

Use this prompt when an agent is configuring a page:
Use squasher status-pages ..., squasher subscribers ..., the Query Guide, or MCP search("statusPages") followed by execute.

​
Post-incident reviews

After an incident is both published and resolved, open its Public incident card and save a public HTTP or HTTPS review link. The resolved incident on the status page shows Post-incident review. Clear the field to remove the link. Saving the same link twice does not create duplicate activity records. Use a page that is safe to share with your customers. Links with embedded credentials are rejected. Editing the link requires status_pages:write.

​
Public update history and feeds

Public pages show the latest 50 published incident updates, newest first. Each entry keeps its publication time, update label, and public message. A later update adds an entry to this history. Internal incident titles and private activity do not appear in the feed. Use the RSS or Atom link at the bottom of a public page to follow its updates in a feed reader. On managed subdomains and custom domains, the feed paths are /rss.xml and /atom.xml. For a page at /status/<page-id>/<slug>, append /rss.xml or /atom.xml to that path. Feeds need no login and contain the same latest 50 published updates as the public history. Each update has a stable ID, so a reader can identify entries it has already received. Unpublished incidents are removed from both feeds and the page.