Frequently Asked Questions

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

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,313+ 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 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 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 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.

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 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. Enterprise plans 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.

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.