Status Pages

Status Pages provide a public uptime dashboard for your product or service. Visitors can check whether your systems are operational, view uptime history, read incident updates, and subscribe to notifications — all without contacting your support team.

Status Page List

The main view shows all status pages in your workspace. Each entry displays:

• Title: The name shown on the public status page.
• Slug: The URL identifier — your public page is at /status/:slug.
• Status: Active (publicly visible) or Inactive (hidden).
• Monitor count: How many monitors are assigned to this page.
• Subscriber count: How many people are subscribed to updates.

Click New status page to create one. You only need a title to get started.

Overview Tab

The Overview tab gives you a real-time summary of system health:

• Overall status: Computed from all assigned monitors — Operational, Degraded, Partial Outage, or Major Outage.
• Monitors up/down: Count of monitors currently passing or failing checks.
• Uptime (30d): Average uptime percentage across all monitors over the last 30 days.
• Active incidents: Number of open (unresolved) incidents.
• Uptime bar: A visual bar of recent check results — green for success, yellow for degraded, red for failure. Hover for details.
• Recent activity: The last check results across all assigned monitors with status, response time, and timestamp.

The public page URL is shown with a copy button for easy sharing.

Monitors Tab

Monitors are endpoints that get checked on a schedule. Each monitor pings a URL and records whether it responded successfully.

Creating a Monitor

From the Monitors tab, click Add monitor to either select an existing monitor or create a new one inline:

• Name: A descriptive label (e.g., "API Server", "Website", "Payment Webhook").
• URL: The full endpoint URL to check (e.g., https://api.example.com/health).
• Check interval: How often to ping — 1 min, 5 min, 10 min, 30 min, or 60 min.

Monitor Configuration

Each monitor has additional settings accessible from the monitor edit:

• HTTP Method: GET (default), POST, or HEAD.
• Timeout: How long to wait for a response — 5s, 10s, or 30s.
• Expected status code: The HTTP status code to accept as success. Leave blank to accept any 2xx response.
• Keyword match: An optional string that must appear in the response body for the check to pass. Useful for verifying the response is not an error page.
• Custom headers: JSON object of headers to include in the request (e.g., authorization tokens).
• Request body: For POST monitors, the body to send.
• Confirmations: Number of consecutive failures before the monitor is marked as down and alerts fire. Default is 3, which prevents false alarms from transient network issues.

Monitor States

• Active: Being checked on schedule.
• Paused: Not being checked. Use this during known deployments or when you want to temporarily stop monitoring.

How Checks Work

Every minute, the system queries all active monitors whose next check is due. For each:

1. An HTTP request is sent with the configured method, headers, and timeout.
2. The response status code, response time, and body are evaluated.
3. A check record is stored with the result (SUCCESS, FAILURE, or DEGRADED).
4. If the check fails, the consecutive failure counter increments. Once it reaches the confirmation threshold, an incident is auto-created on all linked status pages.
5. When a previously-failing monitor recovers, incidents are auto-resolved and recovery notifications are sent.

Uptime Calculation

Uptime is calculated as: successful checks / total checks * 100 over the requested period (24h, 7d, 30d, or 90d).

The 90-day uptime bar on the public page shows one segment per day:

• Green: 100% uptime that day.
• Yellow: 95-99.9% uptime (some failures).
• Red: Below 95% uptime.
• Gray: No check data for that day.

Incidents Tab

Incidents track service disruptions and communicate status to your users.

Creating an Incident

Click Create incident to manually report an issue:

• Title: A short description (e.g., "API latency spike", "Database connectivity issue").
• Severity: Minor (degraded non-critical feature), Major (core feature affected), or Critical (full service outage).
• Status: Investigating (default), Identified, Monitoring, or Resolved.
• Message: The initial update message explaining what's happening.
• Affected monitors: Select which monitors are impacted.

Incident Lifecycle

Incidents progress through statuses:

1. Investigating: You're aware of the issue and looking into it.
2. Identified: The root cause has been found.
3. Monitoring: A fix has been applied and you're watching for recurrence.
4. Resolved: The issue is fully resolved.

Each status change should include an update message explaining what changed. All confirmed subscribers receive an email for each update.

Auto-Created Incidents

When a monitor fails enough consecutive checks (reaching the confirmation threshold), an incident is automatically created on all status pages that include that monitor. The incident:

• Has the title "[Monitor name] is down".
• Is marked as auto-created.
• Is automatically resolved when the monitor recovers.

You can add manual updates to auto-created incidents to provide more context.

Maintenance Tab

Maintenance windows let you schedule planned downtime and communicate it to users.

Scheduling Maintenance

Click Schedule maintenance to create a window:

• Title: What's being maintained (e.g., "Database migration", "Infrastructure upgrade").
• Description: Optional details about the maintenance.
• Start / End time: The maintenance window.
• Auto-suppress: When enabled (default), monitor alerts are silenced during the window. Monitors still run checks, but failures won't trigger incidents or notifications.

Upcoming maintenance windows appear on the public status page as informational notices.

Subscribers Tab

Subscribers receive email notifications when incidents are created, updated, or resolved.

How Subscription Works

• Public: Visitors can subscribe from the public status page by entering their email. They receive a confirmation email and must click the link to confirm.
• Admin: You can add subscribers directly from the Subscribers tab. Admin-added subscribers are auto-confirmed (no confirmation email needed).
• Unsubscribe: Every notification email includes an unsubscribe link. You can also remove subscribers from the admin tab.

Subscribers are notified when:

• A new incident is created.
• An incident status is updated (e.g., moved from Investigating to Identified).
• An incident is resolved.

Settings Tab

The Settings tab controls the status page configuration and branding.

Page Settings

• Title: The name shown on the public page header.
• Slug: The URL identifier. Your public page is at /status/:slug.
• Description: Optional text shown below the title on the public page.
• Status: Active (publicly accessible) or Inactive (returns 404).

Branding

Customize the public page appearance:

• Primary color: The accent color used for buttons, badges, and highlights.
• Background color: The page background.
• Text color: The main text color.

Default colors match the Foundaro brand (teal green). Changes are reflected immediately on the public page.

Embed & Badge

• Public URL: The direct link to your status page. Share this in your product footer, docs, or support page.
• Embed code: An iframe snippet you can paste into any external website to embed your status page.
• Badge: An SVG image URL that shows your current status. Embed it in your README, docs, or marketing site.

Public Status Page

The public page at /status/:slug shows:

1. Overall status badge: Color-coded pill showing system health.
2. Active incidents: Alert banners for any ongoing issues with severity and latest update.
3. Upcoming maintenance: Notices for scheduled maintenance windows.
4. Monitor list: Each monitor with current status, 90-day uptime bar, uptime percentage, and last 10 check results as colored pips.
5. Incident history: Timeline of recent incidents with expandable update details.
6. Subscribe form: Email input for visitors to subscribe to updates.

The page is self-contained (no external dependencies), supports dark mode, and works on mobile.

Data Retention

• Monitor checks: Stored for 90 days, then automatically cleaned up.
• Resolved incidents: Kept indefinitely.
• Expired maintenance windows: Cleaned up after 30 days.
• Unconfirmed subscribers: Removed after 48 hours if they don't confirm.

Tips

• Start with one status page and a few critical monitors. You can add more as you identify which endpoints matter most.
• Set check intervals based on criticality: 1 minute for payment endpoints, 5 minutes for APIs, 10+ minutes for marketing sites.
• Use keyword matching to catch silent failures — an endpoint that returns 200 but shows an error page.
• Keep incident updates concise and factual. Users want to know: what's broken, what you're doing, and when it'll be fixed.
• Link your status page from your product's footer, help center, and error pages so users find it when they need it.