-
Notifications
You must be signed in to change notification settings - Fork 132
Open
Labels
Description
🎯 Bounty: Uptime Monitoring Alarm Integration
Bounty: $15
Depends on: #267 (Alarms System)
Overview
Integrate the alarms system with uptime monitoring to trigger notifications when a site goes down or comes back up. Users should be able to assign alarms to their monitored websites and receive notifications via their configured channels (Slack, Discord, Email, Webhook).
Requirements
1. Uptime Trigger Integration (Required)
Connect the uptime monitoring service to the alarms system.
Trigger Events:
- Site goes down (consecutive failures threshold met)
- Site comes back up (recovery)
- Response time exceeds threshold (optional/stretch)
Acceptance Criteria:
- Uptime service checks for alarms assigned to the website
- Triggers alarm when site status changes (up → down, down → up)
- Respects configurable thresholds (e.g., alert after X consecutive failures)
- Prevents duplicate notifications (don't spam on every check)
- Logs alarm trigger history
2. Alarm Assignment UI (Required)
Allow users to assign alarms to monitored websites.
UI Requirements:
- Uptime monitoring page shows assigned alarms
- Quick-assign dropdown to add existing alarms
- Option to create new alarm directly from uptime page
- Visual indicator showing which alarms are active
Acceptance Criteria:
- Alarm assignment UI in uptime monitoring section
- Matches existing dashboard design patterns
- Mobile responsive
- Uses existing UI components
3. Notification Content (Required)
Send rich, informative notifications when alarms trigger.
Down Notification Content:
- Website URL
- Time detected
- HTTP status code (if available)
- Response time (if available)
- Number of consecutive failures
- Link to uptime dashboard
Up Notification Content:
- Website URL
- Time recovered
- Downtime duration
- Link to uptime dashboard
Acceptance Criteria:
- Uses
@databuddy/notificationspackage helpers - Notifications include all relevant site details
- Channel-specific formatting (Slack blocks, Discord embeds, HTML email)
- Professional, clean design matching Databuddy branding
4. Testing (Required)
Acceptance Criteria:
- Unit tests for alarm trigger logic
- Test threshold behavior (only trigger after X failures)
- Test duplicate prevention (no spam)
- Test both down and up notifications
- Test multi-channel delivery
Technical Requirements
- Follow existing codebase patterns in
apps/uptime/ - Use
@databuddy/notificationspackage for sending notifications - TypeScript with strict types (no
any,unknown, ornever) - Use
dayjsfor time calculations and formatting - Proper error handling (don't crash uptime service on notification failure)
Files to Reference
apps/uptime/src/- Uptime monitoring servicepackages/notifications/- Notification providers and helperspackages/db/src/drizzle/schema.ts- Database schema (alarms table from 🎯 Bounty: Alarms System - Database, API & Dashboard UI #267)apps/dashboard/app/(main)/websites/[id]/uptime/- Uptime dashboard UI
Example Usage
import { sendSlackWebhook, sendDiscordWebhook } from "@databuddy/notifications";
// When site goes down
await sendSlackWebhook(alarm.slack_webhook_url, {
title: "🔴 Site Down: example.com",
message: "Your website is not responding.",
priority: "urgent",
metadata: {
url: "https://example.com",
status: 503,
downSince: "2 minutes ago",
consecutiveFailures: 3,
},
});
// When site recovers
await sendDiscordWebhook(alarm.discord_webhook_url, {
title: "🟢 Site Recovered: example.com",
message: "Your website is back online.",
priority: "normal",
metadata: {
url: "https://example.com",
downtimeDuration: "5 minutes",
recoveredAt: new Date().toISOString(),
},
});Submission Requirements
- All code follows linting rules (run
bun run lint) - Type checks pass (run
bun run check-types) - Tests pass
- PR includes screenshots of notification examples
- PR description explains implementation choices
Questions?
Comment on this issue for any clarification needed before starting.