How to Configure Notifications per Monitor (with Test Message)
The most common mistake teams make with monitoring is treating all notifications equally. Every alert goes to the same channel, every monitor uses the same notification settings, and every team member gets paged for every issue. The result is alert fatigue: people start ignoring notifications because too many of them are not actionable, and eventually they miss the critical alerts that really matter. The solution is per-monitor notification configuration, where each monitor sends alerts to the right channel for its specific importance and audience.
UptyBots lets you configure notification settings per monitor, giving you full control over which channels receive alerts and when. Production websites can page on-call engineers via Telegram immediately. Internal admin tools can send quiet emails. Marketing pages can post to a Slack channel that nobody monitors urgently. Each monitor matches its alerting to its actual importance, eliminating the noise that destroys monitoring effectiveness. This guide walks through how to set this up properly and how to verify it works before relying on it during a real incident.
1. Open Notification Settings
Go to your Monitors list and select the monitor you want to customize. In the monitor details, click the Notifications tab. From here, you will see all available channels — Email, Telegram, and Webhooks. Each channel can be enabled or disabled independently, and changes apply instantly without restarting the monitor.
The per-monitor configuration is crucial because different monitors have different importance levels. A failed health check on your main production website needs to wake up the on-call engineer immediately. A failed check on a marketing landing page can wait until business hours. A failed check on an internal staging server may not need any notification at all — just a dashboard entry to look at later.
2. Choose When to Notify
To avoid unnecessary alerts, you can set triggers for specific events. Not every state change deserves a notification:
- 🔴 Down Alerts — when your monitor fails a check. The most common trigger.
- 🟢 Up Alerts — when the monitor recovers and becomes available again. Useful for confirming incident resolution.
- ⚠️ Performance Warnings — when latency exceeds your defined threshold. Catches degradation before hard failure.
- SSL expiration warnings — for SSL monitors approaching expiration.
- Domain expiration warnings — for domain monitors approaching expiration.
Configure each trigger separately. You might want immediate Telegram alerts for down events but only daily email summaries for performance warnings. This level of granularity is what separates effective monitoring from noisy monitoring.
3. Send a Test Notification
Before relying on your configuration, always verify that your alerts are working correctly. Many monitoring setups silently fail because nobody tested them — the engineer assumes alerts are configured properly, but the first time a real incident occurs, the alerts fail to deliver because of a wrong API key, a deleted Telegram bot, or an expired webhook URL.
Use the Send Test Notification button to send a sample alert through each enabled channel. Verify that you actually receive the test message in each channel before considering the setup complete.
- Email → You will get a message with "Test Alert from UptyBots" in the subject line. Check your spam folder if it does not arrive within a minute.
- Telegram → The bot will send a quick "Test message successful" notification to the configured chat.
- Webhook → A JSON payload will be delivered to your endpoint immediately. Check your webhook endpoint logs to confirm receipt.
Each test message helps confirm that your integration, credentials, and delivery routes are valid. Test alerts after every configuration change, after credential rotations, and periodically (monthly or quarterly) to verify everything still works.
Strategies for Per-Monitor Notification Configuration
Priority-Based Routing
Group monitors into priority levels and configure notifications accordingly:
- Critical (P0): Production-critical services. Notify via Telegram + email + webhook to PagerDuty. Immediate response required.
- High (P1): Important production services. Notify via Telegram + email. Respond within 15 minutes.
- Medium (P2): Internal tools, staging environments. Notify via email only. Respond within hours.
- Low (P3): Non-critical services. Dashboard only, no notifications. Review during regular hours.
Time-Based Routing
Different times of day call for different notification strategies:
- Business hours: Email and Slack are sufficient because someone is at their desk.
- After hours: Telegram or SMS to the on-call engineer.
- Weekends: Same as after hours, possibly with longer escalation delays.
- Holidays: Adjusted on-call rotation with appropriate notification routing.
Audience-Based Routing
Different stakeholders care about different things:
- Engineering: Technical alerts via developer-friendly channels.
- Operations: Infrastructure alerts via ops-focused channels.
- Management: Summary reports via email rather than real-time alerts.
- Customer success: Customer-facing incidents via Slack channels they monitor.
Common Mistakes to Avoid
- Notifying everyone for everything. Causes alert fatigue and missed real alerts.
- Notifying nobody. The opposite extreme — alerts go to a dashboard nobody checks.
- Not testing alerts. Many alert systems silently fail because nobody verified delivery.
- Same configuration for all monitors. Loses the value of per-monitor flexibility.
- Email-only setup. Email is too slow for emergencies.
- Single notification channel. If that channel fails, you miss the alert entirely.
- Forgetting about credential rotation. API keys expire, bots get revoked. Periodic testing catches these.
- Not updating after team changes. Notifications still go to people who left the company.
4. Reliable Alerts You Can Trust
With per-monitor configuration, you will never miss a real incident — and you will stop wasting time on unnecessary alerts. The combination of granular control, multi-channel delivery, and tested integrations gives you alerting that actually works when it matters. UptyBots ensures your notifications are relevant, precise, and fully tested before they matter.
Webhook Integration Examples
Webhooks are the most flexible notification channel because they can integrate with any system that accepts HTTP POST requests. Common webhook destinations:
- Slack: Post to a specific channel via Slack webhook URL.
- Discord: Post to a specific channel via Discord webhook URL.
- Microsoft Teams: Use the Incoming Webhook connector.
- PagerDuty: Trigger PagerDuty incidents via their Events API.
- OpsGenie: Trigger OpsGenie alerts via their Alert API.
- Custom backends: Build your own integration with any system.
- Automation platforms: Zapier, Make, n8n for complex workflows.
Frequently Asked Questions
How many notification channels can I configure per monitor?
All available channels can be enabled simultaneously per monitor. Email, Telegram, and webhooks can all fire for the same alert if you want maximum visibility.
What if a notification fails to deliver?
UptyBots retries failed deliveries and logs delivery status. Check the monitor's notification history to see which alerts were successfully delivered.
Can I have different settings for different team members?
Yes. You can configure notifications to go to specific email addresses or Telegram chats. Each team member can have their own preferred notification routing.
How often should I test alerts?
After every configuration change. Also periodically (monthly or quarterly) to verify nothing has broken. After any credential rotation or team change.
Can I temporarily mute alerts during maintenance?
Yes. UptyBots supports temporarily disabling notifications during planned maintenance, so you do not get woken up by expected downtime.
Conclusion
Per-monitor notification configuration is the difference between alerting that protects your services and alerting that drowns your team in noise. Configure each monitor's notifications based on its actual importance, test the alerts before relying on them, and maintain the configuration as your team and infrastructure change. The investment pays off every time a real incident happens and the right people are notified through the right channel at the right time.