Frequently Asked Questions

Mention @servicealert investigate in any Slack channel and within seconds the agent posts a threaded investigation containing four things: probable root-cause hypotheses ranked by confidence, the actual log lines that triggered the call, the most-recent deploy that touched the affected service, and a one-click code-pointer link to the suspect file in your GitHub repo.

Slack reactions act as actions: a thumbs-up promotes the leading hypothesis to the channel, an X silences a flapping monitor with a stated reason, and a siren promotes the alert to a full declared incident with all the responder routing that comes with it.

Confidence is calibrated weekly against incident outcomes, so the agent gets sharper over time, not just chattier. Available on Business and Enterprise plans.

Yes. Drop a single Go binary onto any host (your AWS region, an on-prem datacenter, a customer’s VPC, a branch office) and it registers itself with your account, joins your monitor pool, and shows up as another check-running region next to ServiceAlert’s central probes.

Per-monitor alert quorum lets you require any, majority, or all configured regions to agree before an alert fires — so a single-region carrier flake on one corner of the internet no longer pages you at 3am.

1. Open Monitoring Agents, Settings → Admin Dashboard → Monitoring Agents.
2. Generate a registration token, click Add Agent, copy the env value.
3. Run the register-agent CLI on your host with --out=/etc/servicealert-agent.env.
4. Install the systemd unit — the agent ships with proper Linux capabilities so ICMP/TCP probes run without root.

For most teams, yes. Native on-call rotations land in the dashboard with timezone-aware shifts, cover-request workflow, commander auto-assignment when an incident is declared, an iCal calendar feed (subscribe in Google Calendar, iOS Calendar, or Outlook), and Postmark-delivered email reminders for upcoming shifts.

If your org needs PagerDuty’s deeper escalation engine (escalation policies, advanced suppression, voice / SMS routing), the existing PagerDuty + Opsgenie outbound integrations still work — just configure ServiceAlert as the alert source and PagerDuty as the destination.

Yes, on Business and Enterprise plans, with no certificate management on your end. 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.

Within ~5 minutes of the CNAME taking effect, our cert-issuance worker runs Let’s Encrypt HTTP-01, writes a per-domain nginx server block, reloads, and your page goes live with a valid TLS cert. Renewals are automatic.

Atlassian StatusPage charges $79/mo extra for custom-domain support. We don’t.

The public /outage-map aggregates three independent ledgers of outages. The first two have been live for a while: vendor-declared (status feeds the vendor publishes themselves) and ServiceAlert-detected (anomalies our pipeline catches before the vendor admits anything).

The third ledger, new in May 2026, is BGP anomalies. We poll RIPE’s Routing Information Service nightly for country-level prefix counts across 50+ countries and flag any country whose prefix count drops more than 5% below its 7-day trailing median. That catches Telegram in Pakistan, Twitter in Turkey, and ISP-wide events whose vendors will never put up a status page.

Free, public, no signup required. Each anomaly card links to its source data on RIPEstat.

ServiceAlert.ai tracks 2,321+ 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.

The number of services you can monitor depends on your plan. Personal plans include up to 3 services, Pro plans include up to 50, and Business and Enterprise plans are unlimited.

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, Enter one or more email addresses that should receive notifications. 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, Pick a minimum interval (30 min - 4 hrs) between repeated alerts for the same service to avoid inbox flooding.
6. Save & test, Click Save Preferences, then use Send Test Email to verify delivery.

Email alerts require a Pro or Enterprise plan and at least one monitored service selected in your Service Selection settings.

Teams integration uses the Microsoft Graph API to post messages to your channel. You'll need Azure AD admin access to complete the setup.

1. Open Azure Portal, Go to Azure AD App Registrations and click New registration.
2. Register the app, Enter a name like "ServiceAlert Teams Bot", select Accounts in this organizational directory only, and click Register.
3. Add API permissions, Navigate to API permissions → Add a permission → Microsoft Graph → Application permissions. Search for and add ChannelMessage.Send.
4. Grant admin consent, Click Grant admin consent for [Your Organization]. This requires Azure AD admin privileges.
5. Create a client secret, Go to Certificates & secrets → New client secret. Set a description and expiration, then click Add. Copy the secret value immediately, you won't be able to see it again.
6. Copy your IDs, Go to Overview and copy the Application (client) ID and Directory (tenant) ID.

7. Get a link to your channel, In Microsoft Teams, right-click the channel name and select Get link to channel.
8. Extract the IDs from the URL, The link contains:
   Team ID: the groupId parameter (the GUID).
   Channel ID: decode the path after /channel/ (replace %3A with : and %40 with @).

Requires Azure AD admin privileges. Contact your IT department if you don't have access. Teams alerts are available on the Enterprise plan.

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 workspace admin approval to add apps if your workspace restricts app installations. Slack alerts are available on the Enterprise plan.

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 available on the Enterprise plan.

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 available on the Enterprise plan.

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 available on Pro plans and above. Your signing secret is stored securely and never exposed to the browser.

Early Signals is a crowdsourced alerting feature. When multiple users report issues with a service within a short time window, ServiceAlert.ai detects the spike and can notify you, often before the vendor's official status page is updated.

1. Enable Early Signals, Go to the Early Signals section in the sidebar and toggle alerts on.
2. Set a threshold, Choose how many user reports within 15 minutes should trigger an alert (5, 10, 15, 20, or 25).
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 Signals are available on Pro and Enterprise plans. You can also report issues yourself on any service detail page.

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.

Teams let you organize your members into units, like NOC, SOC, Engineering, or DevOps. Each team can have its own service list and dashboard layout, so different parts of your organization only see what's relevant to them.

Creating a team:

1. Go to Team Management in the sidebar.
2. Under Teams, type a name and optional description, then click Create Team.
3. Assign members to the team using the Team dropdown in the members table.

Configuring a team's dashboard:

1. Click the grid icon next to a team name to open its configuration.
2. Select which services the team should monitor, members will only see these services on their dashboard.
3. Toggle dashboard sections on or off (Trending Now, Live Activity, Monitor Health) to customize the team's view.

Team Leads: You can promote any team member to Lead by clicking the star icon next to their name. Leads can edit their team's service selection and dashboard layout without needing Business Admin access.

Teams are available on Business and Enterprise plans. Each member can belong to one team at a time. Members not assigned to a team see the default company-wide dashboard.

Team Monitors are uptime monitors owned by a team rather than an individual user. Any Business Admin or Team Lead can create a team monitor by assigning it to a team when adding or editing a monitor. Once assigned, the monitor is visible to all team members in the team dashboard view.

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. Only Business Admins and Team Leads can pause, edit, or delete them.

Team Monitors are available on Business and Enterprise plans. Monitors without a team assignment remain personal and are not visible to other team members.

Business Admins and Team Leads see an Assign to Team dropdown in the monitor creation and editing forms. Regular members do not see this option.

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 (visible to BAs and Leads only), 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.

To move an existing monitor to a team, edit it and change the Assign to Team field. You can also unassign it by selecting None (Personal).

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 Pro, Business, and Enterprise plans.

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 Pro, Business, and Enterprise plans. For one-time lookups, use the free DNS Lookup tool.

Status Pages let you create a public (or private) page showing the real-time status of your monitors, perfect for sharing uptime with customers or 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.

Status Pages are available on Business and Enterprise plans. Each page can include any combination of your monitors.

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 subscribers in real time

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. Your page is live at https://yourchoice.status.servicealert.ai within seconds.

Subscribers can sign up for incident notifications directly on the page (email + RSS). For full white-labelling on your own domain (e.g. status.yourbrand.com), the Enterprise plan supports custom domain setup with your own TLS cert.

It means the vendor's own official status page is consistently late to acknowledge incidents. ServiceAlert.ai grades every monitored vendor's status page on an A-F scale based on how quickly they admit there's a problem after we (and our community) detect one. The full grading methodology and per-vendor leaderboard live at /accuracy.

We only show the warning callout when the grade is D or F, honest vendors (A/B/C) don't get a callout because there's nothing to flag. When you do see one, the message looks like:

"Vendor transparency: D, 1Password's official status page is unreliable, on average 20.1 hours late to acknowledge incidents."

This is one of ServiceAlert's unique signals, no other status aggregator publishes vendor accountability data this way.

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.

User reports feed into the Early Warning Signal pipeline. When the report volume for a service spikes above the baseline threshold, the spike chart turns red, the service is flagged as having an active incident, and subscribers are notified, usually 10-30 minutes before the vendor's own status page acknowledges the outage.

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 (Check Settings on the create / edit form) that controls how many regions must agree the target is down before alerts fire. Recovery alerts are never gated, the moment any region sees the target come back up, alerts dispatch normally.

• 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.

Available on Business and Enterprise plans. 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.