Setting Up Alerts

Alerts are the backbone of effective monitoring. Pingara's alert system ensures your team is notified the moment an issue is detected, and again when it's resolved.

How Alerts Work

When Pingara detects an issue with one of your monitors, it follows this flow:

1. Check fails - HTTP request returns unexpected status, times out, or keyword is missing
2. Consecutive failures confirmed - 2 back-to-back failures triggers an incident
3. Alert policies evaluated - Pingara checks which policies apply to the monitor
4. Notifications dispatched - Messages sent to all configured channels (email, Slack, etc.)
5. Recovery detected - 2 consecutive successes resolve the incident
6. Recovery alert sent - Team is notified that the issue is resolved

No manual intervention needed. The entire lifecycle is automatic.

Alert Policies

An alert policy is a set of rules that determines what triggers a notification and who gets notified.

Creating a Policy

1. Navigate to Settings → Alert Policies
2. Click Create Policy
3. Give it a descriptive name (e.g., "Production Alerts" or "On-Call Team")
4. Configure the alert triggers
5. Add notification channels
6. Save

Alert Triggers

Each policy has five toggles that control when notifications fire:

Alert on Down

This is the most important trigger. When enabled, your team receives a notification as soon as an incident is created, after 2 consecutive check failures.

Example notification:

🔴 Monitor Down: api.example.com
Status: Investigating
Error: Connection timeout
Region: US East (N. Virginia)
Started: 2024-01-15 14:32 UTC

Alert on Recovery

Equally important as down alerts. When enabled, your team knows the moment service is restored.

Example notification:

🟢 Monitor Recovered: api.example.com
Status: Resolved
Duration: 12 minutes
Resolved: 2024-01-15 14:44 UTC

Best practice: Always enable both Down and Recovery alerts. Without recovery notifications, your team may waste time investigating issues that have already resolved.

Alert on Degraded

Triggers when a monitor's response time consistently exceeds its slow-response threshold, even though the service is technically "up." This is a separate, raw-latency rule from Apdex. Apdex is computed for reporting only and feeds no detection path. The threshold defaults to 4× your Apdex threshold (2000ms if Apdex is 500ms) for 3 consecutive slow checks, and is quorum-confirmed across regions the same way a Down status is. A second cause feeds the same rule and the same alert: a keyword mismatch on a monitor whose keyword-failure severity is set to Degraded (the default for new monitors) counts as a degraded check rather than a failed one, so "Degraded" can mean "answered, but with the wrong content" as well as "answered, but slowly".

When to enable:

• Performance-sensitive APIs
• E-commerce sites where latency impacts conversions
• SLA-bound services

When to skip:

• Non-critical internal tools
• Services with naturally variable response times

Alert on SSL Expiry

Sends milestone-based warnings as your SSL certificate approaches expiry. Default warning thresholds are 30, 14, and 7 days before expiry.

Pingara sends one alert per threshold. You won't be spammed with repeated warnings at the same milestone.

Escalation

Escalation notices aren't a separate alert type. They're follow-ups to the down alert for an incident that's still unresolved, so Pingara gates them with the same dispatch decision it makes for the original down alert.

In practice: whether escalation notices go out is decided once, across every enabled policy governing the monitor, not by any single policy's toggle alone. If every governing policy has Alert on Down off, no escalation notices go out for that monitor. But if even one governing policy still has it on, escalation notices reach every channel across every governing policy, including a policy whose own Alert on Down is off. A policy's toggle is its vote on whether the alert dispatches at all, not a filter on which channels receive it. There's no separate "Alert on Escalation" toggle to turn on instead.

The same rule applies one level down, at the individual level. Two layers of preferences control who gets notified:

A policy toggle isn't a per-channel filter. It's that policy's vote on whether an alert type dispatches at all for the monitors it governs. When a monitor is covered by more than one enabled policy, the alert dispatches if any of them still has the trigger on, and once it dispatches, it reaches every channel across every governing policy, including the channels of a policy whose own toggle is off. Silence requires every enabled policy governing the monitor to have the toggle off, and when that happens, nothing goes out at all, including the default email organization members get when no channel already covers them, a fallback that used to arrive regardless of the toggle. A monitor with no alert policy governing it is unaffected either way: the fallback is a floor for an organization that hasn't configured alerting, not something a policy's toggle can override.

A channel tied to a specific person, such as an individual's email address, checks that person's own preferences first. There, the Incident Alerts toggle is what governs down alerts, and by extension, escalation notices, for that person specifically: turning it off silences both for that person no matter what any policy's toggle decides.

Both layers share one idiom: an unset preference defaults to on. A toggle only blocks a notification once someone explicitly turns it off. A team member with no saved preferences receives every alert type their governing policies dispatch.

Troubleshooting tip: If escalation notices aren't arriving, don't look for an "Alert on Escalation" setting, because it doesn't exist. Check whether every enabled policy governing the monitor has Alert on Down off. One policy still having it on is enough to deliver to everyone, this policy's own channels included. Then check the recipient's own Incident Alerts preference under Settings → Notifications, which silences delivery for that person alone regardless of any policy.

Linking Policies to Monitors

Alert policies are automatically linked to new monitors when created. You can also manually manage which policies apply to each monitor.

Automatic Linking

When you create a new monitor, Pingara links it to all enabled alert policies in your organization. This ensures new monitors are covered immediately.

Manual Linking

To add or remove a policy from a specific monitor:

1. Go to Monitors → [Your Monitor] → Settings
2. Scroll to Alert Rules
3. Toggle policies on or off

This lets you create targeted policies, for example, a "Critical Only" policy that only applies to production monitors.

Escalation and Repeat Notifications

Escalation Rules

Escalation ensures that unresolved incidents get attention from the right people:

• Immediate - First notification goes to the primary channel (e.g., Slack)
• After X minutes - If unacknowledged, escalate to secondary channel (e.g., email to team lead)
• After Y minutes - Escalate further (e.g., PagerDuty to on-call engineer)

Repeat Notifications

For critical monitors, configure repeat notifications to prevent alerts from being missed:

• Repeat every 15 minutes - Good for production outages
• Repeat every 30 minutes - Good for important but non-critical services
• No repeat - Single notification only

Tip: Combine escalation with repeat notifications. The first alert goes to Slack; if unresolved after 15 minutes, repeat to email; after 30 minutes, escalate to PagerDuty.

Pause and Resume Alerts

When you pause a monitor (e.g., during planned maintenance), Pingara can optionally notify your team:

• Monitor Paused - "Monitor api.example.com has been paused"
• Monitor Resumed - "Monitor api.example.com has been resumed"

Enable the "Alert on Pause" option in your alert policy if you want visibility into maintenance windows.

Best Practices

Create Separate Policies for Different Environments

Production Alerts → All triggers enabled, Slack + PagerDuty
Staging Alerts    → Down + Recovery only, Slack only
Development       → No alerts (or email digest)

Don't Over-Alert

Alert fatigue is real. If your team receives too many notifications, they start ignoring them, including critical ones.

• Only enable Degraded alerts for truly performance-sensitive services
• Use appropriate check intervals (30s for critical, 5m for standard)
• Set a realistic slow-response threshold (it defaults to 4x your Apdex threshold) to avoid false degradation alerts
• Mute alert types you personally don't need under Settings → Notifications. This changes what's sent to you directly and doesn't affect what your team's shared channels receive
• For monitors where response time matters most, add escalation (see "Escalation and Repeat Notifications" above) instead of a louder channel. It repeats and escalates automatically until someone acknowledges the incident

Test Your Alerts

After configuring a policy:

1. Create a test monitor pointing to a non-existent URL
2. Wait for 2 check failures
3. Verify notifications arrive on all configured channels
4. Verify recovery notification when you fix/remove the monitor

Keep Channels Updated

Regularly audit your alert channels:

• Are email addresses still valid?
• Are Slack webhooks still active?
• Are the right people receiving notifications?

Next Steps

• Alert Channels - Configure Email, Slack, Teams, and more
• Understanding Incidents - How incidents are created and resolved
• HTTP/HTTPS Monitoring - Configure what you're monitoring