Configuring Alerts for Synthetic Monitoring

Synthetic monitoring is useless if you don't know when things break. supaguard integrates with your existing tools to ensure the right person gets notified at the right time—without drowning your team in noise.

Supported Integrations

supaguard connects directly with the tools your team already uses:

Setting Up an Alert Policy

An Alert Policy defines when and how you are notified. Think of it as the rulebook for your monitoring alerts.

Step 1: Create the Policy

1. Go to Settings → Alert Policies
2. Click "New Policy"
3. Give it a descriptive name (e.g., "Critical — Page On-Call" or "Warning — Slack Only")

Step 2: Choose Your Channels

Select one or more notification channels. Each channel receives the same alert, so you can broadcast to both Slack and PagerDuty simultaneously.

[!TIP] Start with Slack for general awareness and add PagerDuty only for checks that monitor revenue-critical flows (Login, Checkout, Payments).

Step 3: Configure Trigger Conditions

Set when the alert should fire:

Step 4: Define Escalation Rules

Escalation rules prevent alert fatigue by adding intelligent delays. For example:

1. Wait 2 minutes (filters blips and transient issues)
   ↓
2. Notify Slack #alerts channel
   ↓
3. Wait 15 minutes (if still unresolved)
   ↓
4. Notify PagerDuty → Wake up on-call engineer

This ensures minor blips never reach your pager, while genuine outages escalate quickly.

Assigning Policies to Checks

Once created, assign a policy to any check:

1. Edit your Check
2. Go to the Alerting tab
3. Select your policy from the dropdown
4. Click Save

Now, that check will follow the rules you defined, ensuring you are only bothered when it matters.

[!NOTE] A single check can have only one alert policy, but a single policy can be assigned to multiple checks. Create policies based on severity level, not per-check.

Recommended Alert Architecture

For most teams, we recommend three tiers of alert policies:

Tier 1: Critical (Revenue-Impacting)

• Checks: Login, Checkout, Payment processing
• Channels: PagerDuty + Slack #critical-alerts
• Trigger: Immediate (after Smart Retry confirmation)
• Escalation: Page on-call after 2 minutes

Tier 2: Warning (Important but Non-Urgent)

• Checks: Feature pages, API health, dashboards
• Channels: Slack #monitoring
• Trigger: After 2 consecutive failures
• Escalation: None—investigate during business hours

Tier 3: Informational (Awareness Only)

• Checks: Documentation, status pages, blog
• Channels: Email digest
• Trigger: After 3 consecutive failures
• Escalation: None

Testing Your Alerts

Before going live, always verify your channels work:

1. Navigate to Settings → Alert Policies
2. Click ⋮ on your policy
3. Select Send Test Notification
4. Verify it arrives in the expected channel

[!IMPORTANT] For Slack integrations, make sure the bot has been invited to the target channel. For PagerDuty, verify the integration key is correct by sending a test event.

Best Practices

1. Name policies by severity, not by check — "Critical — Page On-Call" is better than "Login Check Alert"
2. Always enable recovery notifications — Know when issues resolve, not just when they start
3. Use Slack threads — Configure your Slack integration to post updates as thread replies to reduce channel noise
4. Combine with Smart Retries — supaguard verifies failures from multiple regions before alerting, eliminating most false positives before they reach your policy
5. Review alert volume monthly — If a check triggers more than 5 alerts/week, the test script likely needs maintenance

Next Steps

• Slack Integration Setup — Detailed Slack configuration
• PagerDuty Integration — Connect your incident management
• Smart Retries — How false alarms are eliminated before alerting
• Debugging Failures — What to do when an alert fires