How to Configure Notifications per Monitor (with Test Message)
Last year I got woken up at 2 AM because a marketing landing page returned a 503. The page had zero traffic at that hour. Nobody cared. But my monitoring setup treated every alert identically, so the same Telegram message that should have been reserved for a dead checkout endpoint was now buzzing my phone about a page that could have waited until morning. I lay there staring at the ceiling, annoyed at myself for not fixing this months ago.
That was the night I finally sat down and configured notifications per monitor. Different monitors doing different jobs should alert through different channels at different urgency levels. Your SSL certificate check does not need to page anyone at 3 AM. Your payment API going down absolutely does. Once you split these up, monitoring stops being a source of noise and starts being a tool you actually trust.
UptyBots gives you per-monitor control over notification channels. This post walks through how I set mine up, the logic behind each decision, and why you should test every channel before you need it in a real incident.
The Problem with One-Size-Fits-All Alerting
Most people start monitoring the same way. They add their first few monitors, enable email notifications globally, maybe connect Telegram, and call it done. Every monitor fires through every channel. It works fine when you have three monitors.
Then you grow. You add your API endpoint. Your staging environment. Your blog. Your partner portal. Your SSL checks. Your domain expiry watches. Now you have twenty monitors and every single one of them has the same notification settings. Your phone buzzes for a staging server hiccup. Your inbox fills with SSL-expiry-in-30-days reminders for domains that auto-renew. Your webhook fires a PagerDuty incident because a blog post page took 3 seconds to load.
This is alert fatigue. It is the number one reason monitoring fails in practice. The system works perfectly from a technical standpoint. Every alert fires correctly. But the humans receiving them stop paying attention because 90% of the alerts are not actionable. When the real alert comes, the one where the checkout API is returning 500 errors and customers are bouncing, it sits in the same noisy channel as everything else and gets ignored for twenty minutes.
The fix is not fewer monitors. The fix is smarter routing.
How I Think About Monitor Priority
Before touching any notification settings, I sit down and sort my monitors into tiers. This takes ten minutes and saves hours of accumulated frustration later.
Tier 1: Revenue and authentication. These are the monitors where downtime directly costs money or locks users out. Payment endpoints, login flows, checkout pages, core API routes. If these go down, someone needs to know within seconds. Telegram plus webhook to the incident management system. Email too, as a backup channel.
Tier 2: Core product functionality. The dashboard, the main app screens, key integrations. Important, but a five-minute delay in notification is acceptable. Telegram and email. No webhook to PagerDuty because I do not want to wake the on-call engineer at 3 AM for a slow dashboard load.
Tier 3: Supporting services. Documentation site, blog, marketing pages, internal admin tools. Email only. These can wait until someone checks their inbox during business hours.
Tier 4: Informational. Staging environments, dev servers, experimental endpoints. No notifications at all. Dashboard only. Someone will notice during their next work session.
Your tiers will look different from mine. The point is to have them defined before you start clicking buttons. Otherwise you will configure each monitor ad hoc and end up with an inconsistent mess that is just as noisy as the global-everything approach.
Step 1: Open the Monitor's Notification Settings
In UptyBots, go to your Monitors list and select the monitor you want to configure. Click the Notifications tab. You will see the available channels: Email, Telegram, and Webhooks. Each one toggles on and off independently per monitor.
This is the key difference from global notification settings. Global settings define what channels are available and connected. Per-monitor settings control which of those connected channels actually fire for each specific monitor. You might have Telegram connected at the account level but only enable it on your Tier 1 and Tier 2 monitors.
Changes apply immediately. No need to restart the monitor or wait for a sync cycle.
Step 2: Choose What Events Trigger Notifications
Not every state change needs to send an alert. UptyBots lets you pick which events fire notifications:
- Down alerts fire when a monitor fails its check. This is the one everyone enables. Your site returned a 500, your ping timed out, your port is closed. Something broke.
- Up alerts fire when a monitor recovers. I enable these on Tier 1 monitors so I know the incident is over without having to keep refreshing the dashboard. On lower-tier monitors I skip them to reduce noise.
- Performance warnings fire when response time exceeds your threshold. I use these on API monitors where latency matters. A slow API is not down, but it might as well be if your mobile app times out waiting for a response.
- SSL expiration warnings fire as your certificate approaches expiry. I route these to email only. SSL renewals are a business-hours task. Nobody needs a Telegram ping about a cert expiring in 14 days.
- Domain expiration warnings fire as your domain registration approaches expiry. Same logic. Email only, handled during business hours.
The combination of channel selection and event selection gives you fine-grained control. My checkout API monitor sends down and up alerts to Telegram plus webhook, performance warnings to email only, and ignores SSL and domain events entirely because those are handled by separate dedicated monitors.
Step 3: Send a Test Notification
This is the step most people skip. It is also the step that saves you during an actual incident.
I have seen monitoring setups where the Telegram bot was deleted three months ago and nobody knew because no real alerts had fired. I have seen webhook URLs pointing to a staging environment that was decommissioned. I have seen email notifications landing in spam because the sending domain changed and nobody updated the SPF record.
All of these are invisible until you need the alert to actually work. Then you discover the gap at the worst possible moment.
UptyBots has a Send Test Notification button on each channel. Use it. For every channel. On every monitor you care about. Here is what to expect:
- Email: A message arrives with "Test Alert from UptyBots" in the subject line. If it does not show up within a minute, check your spam folder. If it is in spam, whitelist the sender domain now, not later.
- Telegram: The bot sends a "Test message successful" notification to your configured chat. If nothing arrives, verify the bot is still active and the chat ID is correct.
- Webhook: A JSON payload hits your endpoint immediately. Check your receiving system's logs to confirm it arrived and parsed correctly. Pay attention to the response code your endpoint returns. A 200 means delivery succeeded. Anything else means you have a problem to fix.
I test my channels in three situations: after any configuration change, after rotating any credentials (API keys, bot tokens), and on a quarterly schedule even if nothing changed. Credentials expire. Endpoints get decommissioned. Chat groups get archived. Regular testing catches these silent failures before they matter.
Real Configurations from My Setup
Here is how I actually have things wired up. Steal what is useful.
Checkout API (Tier 1)
- Type: API monitor with response body validation
- Down alert: Telegram + Webhook (PagerDuty) + Email
- Up alert: Telegram + Email
- Performance warning: Email only (threshold: 2 seconds)
- Why: Revenue-critical. Every second of downtime costs money. The webhook triggers PagerDuty which handles on-call escalation. Telegram gives instant visibility to the team channel. Email is the backup record.
Marketing Website (Tier 3)
- Type: HTTP monitor
- Down alert: Email only
- Up alert: Disabled
- Performance warning: Disabled
- Why: Nobody is losing money if the marketing site is slow at midnight. An email in the morning is enough. No need to wake anyone.
SSL Certificate Monitor (Tier 3)
- Type: SSL monitor
- SSL expiration warning: Email only
- Down alert: Email + Telegram (if the SSL handshake outright fails, that is a real problem)
- Why: Expiration warnings are administrative. A failed SSL handshake is an active incident that breaks the site for users.
Partner API Integration (Tier 2)
- Type: API monitor
- Down alert: Telegram + Email
- Up alert: Telegram
- Performance warning: Email (threshold: 5 seconds)
- Why: Partners notice when the integration is down and they will email us. We want to know before they do. But it is not PagerDuty-level urgent.
Staging Environment (Tier 4)
- Type: HTTP monitor
- All notifications: Disabled
- Why: Dashboard only. Developers check the dashboard during work hours. No alerts needed.
Webhook Integration Patterns
Webhooks are the most flexible channel because they can talk to anything that accepts an HTTP POST. I have used them with:
- PagerDuty: Trigger incidents via their Events API v2. Map monitor severity to PagerDuty urgency levels.
- OpsGenie: Same idea, different vendor. Their Alert API accepts the same kind of JSON payload.
- Slack: Post to a specific channel via incoming webhook URL. I use this for Tier 2 monitors where the team channel needs visibility but nobody needs to be paged.
- Discord: Same pattern as Slack. Works well for game server monitoring or community-facing projects.
- Microsoft Teams: Incoming Webhook connector. Popular in enterprise environments.
- n8n / Zapier / Make: Route the webhook through an automation platform to build more complex workflows. For example: if monitor X goes down AND monitor Y is still up, then it is probably a regional issue, so notify the regional team.
- Custom backend: Hit your own API to log incidents, update a status page, trigger automated remediation, or do whatever else your infrastructure needs.
The key with webhooks is testing. Unlike email and Telegram where you can visually confirm delivery, webhook failures are silent. Your endpoint might be returning 200 OK but not actually processing the payload. Test end to end: fire a test notification, then verify that the downstream action actually happened (PagerDuty incident created, Slack message posted, database record written).
Mistakes I Have Made (So You Do Not Have To)
Sending everything to Telegram. I thought I wanted maximum visibility. What I got was a Telegram channel with 200 messages a day, most of them low-priority performance warnings. I stopped reading it after a week. Then I missed a real production alert buried in the noise. Never again.
Not testing after credential rotation. Rotated the Telegram bot token as part of a security review. Forgot to update the monitoring configuration. Three weeks later, a real incident happened. Telegram was silent. I found out from a customer complaint.
Using only email for critical monitors. Email is slow. It gets caught in spam filters. It gets lost in a busy inbox. For anything time-critical, you need a push notification channel like Telegram. Email is good as a backup and as a record, but not as your primary alert for a production outage.
Forgetting to disable notifications on decommissioned monitors. We shut down a service but left the monitor running. It alerted every 5 minutes that the service was down. For two days nobody bothered to clean it up because everyone assumed it was "that old alert." When a different, real alert fired during those two days, it got lost in the same assumption.
Configuring one monitor and copying settings to all. Seems efficient. But your blog monitor and your payment API have very different importance levels. Taking two extra minutes per monitor to think about the right channels saves you from alert fatigue down the road.
Not including recovery alerts on critical monitors. Down alerts tell you something broke. Up alerts tell you it is fixed. Without recovery alerts, you keep checking the dashboard manually to see if the service came back. Enable up alerts on anything Tier 1 or Tier 2.
Maintaining Your Configuration Over Time
Setting up per-monitor notifications is not a one-time task. Your infrastructure changes. Team members leave and new ones join. Services get added, retired, or change in importance. Here is what I do quarterly:
- Audit channel connections. Are all Telegram bots still active? Are webhook URLs still valid? Are email addresses still monitored by someone on the team?
- Re-tier your monitors. That experimental API you launched last quarter might now be handling production traffic. Its notifications should be upgraded from Tier 4 to Tier 1.
- Remove dead monitors. Decommissioned services should not have active monitors. They create noise and desensitize the team.
- Fire test notifications. Every channel, every Tier 1 monitor. If something broke silently, you want to find out now, not during an incident.
- Review alert volume. If anyone on the team says they are getting too many alerts, that is a signal to re-evaluate your tier assignments. The goal is signal, not volume.
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
Alert fatigue kills monitoring effectiveness faster than any technical failure. The fix is straightforward: sort your monitors by importance, assign channels that match each tier, pick the right event triggers, and test everything before you need it. It takes thirty minutes to set up properly and saves you from missing the alert that actually matters at 2 AM on a Saturday.
The difference between a monitoring setup that protects your business and one that just generates noise is not the number of monitors or the frequency of checks. It is whether the right person gets the right alert through the right channel at the right time. Per-monitor notification configuration is how you get there.