Frequently Asked Questions

Starter is $29, Team is $99 and Business is $249 per workspace per month in USD, with unlimited members. Billing is monthly; annual self-service checkout is not offered.

Starter includes 10 one-minute uptime monitors, 1 status page and 30-day incident history. Compare all plan limits.

Eligible accounts can start one 14-day trial of Starter, Team or Business without a card. Without a payment method at trial end, the subscription cancels and trial access ends. If you add a payment method, billing starts at the selected monthly price unless you cancel before the trial ends.

During setup, select your vendors, configure a delivery destination and add a monitor. Confirm receipt of a test notification before relying on that destination. Get setup help.

It stays at $10 per user per month with 50 vendor services and 30-day incident history. Pro is closed to new subscriptions and does not include uptime monitors or a customer status page. You will not be switched automatically.

Manage your subscription.

Mention @servicealert investigate in a connected Slack channel to summarize the evidence attached to a declared incident, including recent checks, notes, deployment context, and linked logs.

The assistant can suggest next steps, but responders decide what to do. Available Slack actions depend on the permissions granted to the integration.

Available on Business and Enterprise plans.

Yes. Business and Enterprise accounts can connect monitoring agents in selected cloud regions, datacenters, or private networks. Connected agents appear in the dashboard and can be assigned to uptime checks.

Alert rules can require confirmation from more than one location, which helps distinguish a local routing problem from a broader outage.

1. Open Settings → Monitoring Agents.
2. Select Add Agent and follow the installation instructions shown for your account.
3. Confirm the agent is reporting, then add it to the monitors that need another location.

ServiceAlert supports timezone-aware rotations, cover requests, calendar feeds, and email reminders. A current responder can also be assigned when an incident is declared.

Teams that need complex escalation policies or voice and SMS routing can continue sending ServiceAlert notifications to PagerDuty or Opsgenie.

Yes. Starter and higher plans include status pages with a verified custom domain. ServiceAlert manages TLS for the hostname. Two-step setup:

1. Verify ownership, in the status page editor, enter your custom domain and we generate a TXT record value. Add it at your DNS provider as _servicealert-verify.<your-domain>, click Verify.
2. Add the CNAME, point status.acme.com at cname.servicealert.ai.

After the CNAME is visible, ServiceAlert provisions and renews TLS for the status-page hostname. DNS propagation time varies by provider.

The public outage map separates provider-declared incidents, ServiceAlert detections, and broad network-routing events.

Routing events are shown only after they meet our validation rules. The public page provides a bounded summary; the complete source inventory and detection thresholds are not published.

The map is public and does not require an account.

ServiceAlert.ai tracks 2,362+ cloud services, but alerts are only sent for the ones you select.

1. Go to Service Selection, In the sidebar under Settings, click Service Selection.
2. Browse services, Use the search bar or browse the full list.
3. Toggle services on/off, Click a service to add or remove it from your monitored list.
4. Save, Click Save Preferences to apply your changes.

Starter follows 20; Team and existing Pro subscriptions follow 50. Business and Enterprise include unlimited vendor follows. These are separate from uptime monitors for your own websites and APIs.

Email alerts notify you when your monitored services experience outages, degraded performance, or recover. Here's how to configure them:

1. Navigate to Email Alerts, In the sidebar, click Email Alerts under Integrations.
2. Enable alerts, Toggle the Enable Email Alerts switch to On.
3. Add recipients, Add recipients within your plan’s allowance. Your account email is included by default.
4. Choose alert types, Select which status changes trigger an alert: Major Outage, Partial Outage, Degraded Performance, and/or Recovery.
5. Set a cooldown, Choose a cooldown from the intervals available on your plan to limit repeated alerts for the same service.
6. Save, Click Save Preferences. Paid plans can then use Send Test Email to verify delivery.

Email and browser push alerts are available during your trial and on paid plans. Existing Free accounts retain their current access. Select at least one vendor service and configure delivery. Manual test notifications require a paid plan; saving a follow does not confirm delivery.

Use a Microsoft Teams Workflows webhook. No Entra app registration or client secret is needed.

1. In Teams, create a workflow with the “When a Teams webhook request is received” trigger and Anyone access.
2. Choose the destination channel, save, and copy its complete signed webhook URL.
3. Open Teams settings, save the URL, and send a test notification.

Add a co-owner in Teams for continuity. Existing Graph configurations show Reconnect required until replaced. Teams setup details.

Slack integration uses Incoming Webhooks to post messages to your channel. Setup takes just a few minutes.

1. Go to Slack API, Visit api.slack.com/apps and click Create New App. Choose From scratch.
2. Name your app, Enter a name like "ServiceAlert" and select your workspace. Click Create App.
3. Enable Incoming Webhooks, In the sidebar, click Incoming Webhooks, then toggle Activate Incoming Webhooks to On.
4. Add webhook to workspace, Click Add New Webhook to Workspace. Select the channel where you want alerts and click Allow.
5. Copy the Webhook URL, Copy the URL that appears (starts with https://hooks.slack.com/services/) and paste it into the Slack Alerts settings.

You may need Slack workspace admin approval to add an app. Slack alerts are included with Starter, Team, Business and Enterprise. Slack incident investigation has separate Business and Enterprise requirements.

Google Chat integration uses webhooks to post card-formatted messages directly to a Google Chat space.

1. Open your space, Open Google Chat and navigate to the space where you want to receive alerts.
2. Open space settings, Click the space name at the top, then select Apps & integrations.
3. Manage webhooks, Click Manage webhooks. If you don't see this option, you may need space manager permissions.
4. Create the webhook, Click Add another, name it "ServiceAlert.ai", and click Save.
5. Copy the Webhook URL, Copy the URL that appears (starts with https://chat.googleapis.com/) and paste it into the Google Chat Alerts settings.

You need space manager permissions to create webhooks. Google Chat alerts are included with Starter, Team, Business and Enterprise.

Discord integration uses webhooks to post rich embed messages directly to a Discord channel.

1. Open channel settings, Right-click your channel in Discord (or click the gear icon) and select Edit Channel.
2. Go to Integrations, Click Integrations in the sidebar, then click Webhooks.
3. Create a webhook, Click New Webhook, name it "ServiceAlert.ai".
4. Copy the Webhook URL, Click Copy Webhook URL and paste it into the Discord Alerts settings.

You need the Manage Webhooks permission in the channel. Discord alerts are included with Starter, Team, Business and Enterprise.

Webhooks let you receive alert payloads at any HTTPS endpoint, perfect for integrating with PagerDuty, Opsgenie, Zapier, n8n, or your own custom automation.

1. Enter your endpoint URL, Go to Webhooks in the sidebar and paste your HTTPS endpoint URL.
2. Add a signing secret (optional), Enter a secret string to enable HMAC-SHA256 signature verification. Each request will include an X-ServiceAlert-Signature header.
3. Test the connection, Click Test Webhook to send a test payload and verify your endpoint receives it.
4. Save, Click Save Configuration to start receiving alerts.

Payload events:

• service.status_change, when a monitored service's status changes
• monitor.status_change, when an uptime monitor goes up/down
• service.early_signal, when user reports spike for a service
• test, sent when you click Test Webhook

Verifying signatures: Compute HMAC-SHA256(payload_body, your_secret) and compare with the X-ServiceAlert-Signature header value (format: sha256=<hex_digest>).

Webhook alerts are included with Starter and higher plans; existing Pro vendor webhooks are retained. Your saved signing secret is not returned to the browser.

Early Signals adds validated outage indicators beside official provider status. When an indicator meets the requirements for an alert, ServiceAlert can notify subscribers.

1. Enable Early Signals, Go to the Early Signals section in the sidebar and toggle alerts on.
2. Choose alert settings, Select the services and conditions you want to follow.
3. Configure a notification channel, Early Signals alerts are delivered through your existing channels (Email, Teams, Slack, Google Chat, Discord, or Webhooks). Make sure at least one is enabled.

Early Signal alerts are available on paid plans, including existing Pro subscriptions. Anyone can report an issue on a service detail page; a report by itself does not establish a wider outage.

The alert cooldown sets the minimum time between repeated notifications for the same service. For example, if a service flaps between "Partial Outage" and "Operational" several times within an hour, a 1-hour cooldown ensures you receive only one alert instead of several.

You can set the cooldown to 30 minutes, 1 hour, 2 hours, or 4 hours in your Email Alerts settings. The cooldown applies per service, so alerts for different services are unaffected.

Starter, Team, Business and Enterprise include a paid workspace with unlimited members. After checkout, open Workspace setup to select vendors, configure routing and invite colleagues.

The owner manages membership and ownership. Operators manage monitors; Viewers have read-only access. Invitations must be accepted by the intended account. Sharing an email domain does not automatically grant paid-workspace access.

Company-managed accounts have separate team administration and company roles. The guide explains both paths.

Team monitors belong to the selected workspace or company team and are visible to its members. Paid-workspace Owners and Operators can create and manage them; Viewers can inspect results.

Team monitors appear with a team badge next to their name and are grouped separately from personal monitors. All team members can view check results, sparklines, SSL details, stats, and incidents for team monitors. Management requires the appropriate role in that workspace or company team.

Team monitors are included with Starter and higher workspace plans, within the workspace monitor allowance. Monitors without a team assignment remain personal and are not visible to other team members.

Open your workspace setup page and choose Add a monitor to preselect that workspace. Owners and Operators can create monitors; Viewers cannot.

1. Go to URL Monitors, Click URL Monitors in the sidebar, then click Add Monitor.
2. Fill in Basic Settings, Enter a name, URL or target, and choose the monitor type (HTTP, Ping, TCP, etc.).
3. Assign to Team, In the Assign to Team dropdown (for workspaces you can manage), select the team this monitor belongs to. Leave it as None (Personal) to keep it private.
4. Save, Click Save. The monitor is now owned by the team and visible to all its members.

Workspace setup also lets the owner link eligible personal monitors after reviewing the sharing change. Moving ownership requires access to the destination and is checked by the server.

Team monitors send alerts through two channels:

Personal alerts, If the monitor creator has email, Slack, Teams, or other alert channels configured on their account, those fire as usual when the monitor changes status.

Team email alerts, If your team has a Team Email Address configured and the Also Send Monitor Alerts toggle is on, the team address will receive an alert when any team-owned monitor goes down, and again when it recovers (if recovery alerts are enabled).

Team monitor alerts reuse the same email address and cooldown setting as service status alerts. For the full setup walkthrough, see the Teams & Monitors guide.

The Weekly Digest is a personalized email summary of your monitored services' performance over the past week. It includes uptime percentages, incident counts, and any notable status changes for the services you've selected.

Digests are sent automatically every Monday morning. You can unsubscribe at any time using the link at the bottom of any digest email, or from the digest page.

The Weekly Digest is available on all plans, including Personal.

Domain Expiry monitors check your domain registration dates via WHOIS and alert you before they expire, helping prevent accidental lapses.

1. Go to Domain Expiry, In the sidebar under Monitors, click Domain Expiry.
2. Add a domain, Click Add Domain and enter the domain you want to monitor (e.g., yourcompany.com).
3. Set the monitor type to Domain, Select Domain as the monitor type when creating the monitor.
4. Configure alerts, Choose your preferred alert channels (email, Slack, etc.) to be notified when the domain is approaching expiry.

Domain monitors check registration dates periodically and flag domains nearing expiration. Available on Starter, Team, Business and Enterprise.

DNS monitors watch your DNS records for unexpected changes, helping you detect misconfigurations, hijacking attempts, or propagation issues.

1. Go to DNS Monitors, In the sidebar under Monitors, click DNS Monitors.
2. Add a DNS monitor, Click Add DNS Monitor and enter the domain or hostname you want to watch.
3. Set the monitor type to DNS, Select DNS as the monitor type.
4. Configure alerts, Choose your preferred alert channels to be notified when DNS records change.

DNS monitors track A, AAAA, CNAME, MX, and TXT records. When a record changes from its expected value, you receive an alert.

DNS monitoring is available on Starter, Team, Business and Enterprise. For one-time lookups, use the free DNS Lookup tool.

Status Pages let you create a public or private page showing the latest state of selected monitors for customers or internal stakeholders.

1. Go to Status Pages, In the sidebar under Monitors, click Status Pages.
2. Create a page, Click Create Status Page.
3. Configure it, Enter a title, slug (URL path), optional description, and logo URL.
4. Select monitors, Choose which monitors to display on the page.
5. Publish, Toggle Make this page public and click Create Status Page.

Your status page will be available at servicealert.ai/status/your-slug. You can also add custom CSS for branding.

Starter and Team include one status page; Business includes three. Add monitors you own as components. Password-protected pages require Business or Enterprise.

Incident Management lets your team declare, track, and resolve outages with a full lifecycle (investigating → identified → monitoring → resolved). It lives at /monitor/incidents.

Capabilities:

• Declared incidents, manually open an incident on any monitor with severity (SEV1/SEV2/SEV3), title, and description
• Incident commander assignment, set who owns the response so the team always knows who's driving
• Slack war rooms, if your account is connected via Slack OAuth, declaring a SEV1 or SEV2 incident auto-creates a dedicated inc-{id}-{slug} Slack channel, posts the initial summary, invites assigned responders, and archives the channel on resolve
• Postmortem management, structured templates with inline editing, tied to the incident record
• Outage correlation, ServiceAlert automatically links related incidents across services so you can spot upstream root causes
• Status page integration, declared incidents publish to your branded status page and its subscribers

Incident Management is available on Business and Enterprise plans. Slack war rooms require connecting Slack OAuth in Settings.

Yes. Every customer-branded status page can be served at a free yourbrand.status.servicealert.ai subdomain, no DNS setup required, no custom certificate to manage. The wildcard cert and routing are already in place.

How to set it up:

1. Go to Status Pages in the dashboard sidebar and create or edit a status page.
2. In the editor, fill in the Custom Subdomain field with the slug you want (lowercase letters, numbers, hyphens, 2-63 characters).
3. Toggle Make this page public on, then save.
4. Save the page, then open it at https://yourchoice.status.servicealert.ai.

Subscribers can sign up for incident notifications directly on the page by email or RSS. Status-page owners can use a verified customer domain such as status.yourbrand.com; ServiceAlert provisions and renews TLS for that hostname.

The grade summarizes consistency between two records from the provider’s official source: when ServiceAlert observed an operational-to-disrupted status change and the incident-notice time reported by that source. The observation timestamp is a polling time, not the provider’s exact change time or an independent ServiceAlert outage detection.

We publish a grade only after the source-attested 90-day history, observed status-change count, and matched incident-notice count reach the stated minimums. Smaller samples remain Provisional. A displayed message may say:

"Provider status / incident-notice consistency: D for Example Cloud, with an average 42 min observation-to-notice interval."

The full methodology, sample label, and provider comparison table are available at /accuracy.

On every /status/{service} and /is/{service}-down page there's a "Having issues with this service?" section with four buttons: Service Down, Slow Performance, Errors, and Intermittent Issues. Click the one that matches what you're seeing and your report is added to the live spike chart and geographic heatmap immediately.

Reports are aggregated and may contribute to an additional outage indicator after validation. A single report does not automatically create a provider incident.

Reports are rate-limited to one per service per IP per 15 minutes to prevent abuse. We hash IP addresses with a daily-rotating salt rather than storing them in plaintext.

Every uptime monitor runs in parallel from multiple regions. Each region writes its own row to the check history with the same shape as a single-region check, so dashboards and incident logs work the same way as before.

Regions in production today:

• azure-east, Microsoft Azure US East. The original ServiceAlert worker.
• us-east, Google Cloud us-east4.
• us-central, Google Cloud us-central1.

On the monitor detail page you'll see a row of pills, one per region, with the latest status, response time, and how long ago the check ran. Status pages show "Checks run from N regions" so end-users know coverage at a glance.

Region quorum is a per-monitor setting that controls how many regions must agree the target is down before an outage alert is sent. Recovery notifications are sent when an available region confirms that the target has recovered.

• Any region (default), alert as soon as central reports down. Same as the original single-region behaviour.
• Majority, alert only when more than half of the active regions report down or degraded. Cuts down false alarms when one provider has a flaky path.
• All regions, alert only if every active region agrees. Strictest setting, useful for high-noise monitors that occasionally fail from one region only.

Single-region monitors behave identically across all three settings, so you can leave it on "Any region" until you have evidence of false alarms from a specific region.

That's exactly what multi-region monitoring is for. Common reasons:

• Provider routing issue, one region's upstream network has a temporary path problem to your target. The other regions confirm the target itself is fine.
• Regional firewall / geo-block, your target only accepts traffic from specific regions or providers.
• Hairpin NAT, if the target hostname resolves to the agent's own external IP (for example, a monitor on a domain that points to the same cloud VM the agent runs on), most cloud providers can't route that traffic back to the same VM. The agent detects this and skips the check rather than reporting a false down, so you'll see the region drop off the pill row entirely.

If the noise is bothering you, change Region quorum to Majority or All regions so alerts only fire when consensus is reached. Or restrict the monitor to specific regions via Check from regions on the edit form.

Yes. On the monitor create / edit form, in Check Settings, look for the Check from regions picker. Tick only the region(s) you want, and that monitor will only run there.

Useful when:

• The target is internal-only, reachable only from one network
• The target rate-limits aggressively and three checks per cycle is too many
• You're staging a new monitor and want to verify it before opening it up to all regions

Leaving every box unchecked = use every region (the default).

A service is a named group of related monitors that shares one configuration: team ownership, on-call schedule, runbook URL, and tier. Instead of setting "this goes to the Payments on-call rotation with the Payments runbook" on eight separate monitors, you set it once on the Payments service and assign monitors to it.

When a service field is set, it wins over the same field on the individual monitor. So per-monitor team / on-call / runbook can be left empty if the service decides. Members can still override individually if needed.

The service catalog is available on Starter and higher plans. On-call and dependency features follow their own plan and role requirements. Manage at /monitor/services.

ServiceAlert auto-silences a monitor that's opening incidents in rapid succession, to keep on-call's pager from melting down while you investigate. Triggers:

• 2 or more incidents within 30 minutes: 15-minute silence.
• 5 or more incidents within 24 hours: 60-minute silence.

The silence is visible: the detail page shows a banner with the reason, and the monitor list shows a small badge. Alerts resume automatically when the silence expires.

To resume alerting now, click Wake now on the detail page (or from Slack). To silence manually for a specific window, use the snooze controls on the latest open incident, or ask Claude / MCP to call silence_monitor.

Yes. ServiceAlert ships an MCP (Model Context Protocol) server at https://servicealert.ai/api/mcp. Once configured, you can ask Claude things like "are any of my monitors down right now?" or "silence the noisy database health check for an hour" and it will call the right tool on your behalf.

Eight tools are available: five read-only (list_monitors, get_monitor, list_services, list_incidents, query_status) and three write (silence_monitor, wake_monitor, declare_incident). Write tools prompt for confirmation before invoking and are audit-logged.

Revoke it immediately at /monitor/api-keys. The next request from that key returns 401 with no propagation delay. Then check /audit-logs for any mcp.tool.call events from that key id you don't recognise. Anything unexpected is the attacker's footprint.

Recommended hygiene: name keys per machine (claude-code-laptop, claude-desktop-work) so a single leak doesn't force you to re-config every device. Rotate monthly. Rate limit is 60 requests/minute per key, which caps the blast radius of a stolen key automatically.