🎯 Bounty: Alarms System - Database, API & Dashboard UI

Bounty: $15

Overview

Build a complete alarms system that allows users to create custom notification alarms, configure notification channels (Slack, Discord, Email, Webhook, Teams, Telegram, Google Chat), and assign alarms to trigger on various events (uptime, analytics, errors, etc.).

This issue uses the @databuddy/notifications package located at packages/notifications/.

Requirements

1. Database Schema (Required)

Create the database table(s) and migrations for storing alarms.

Schema Fields:

• id - Unique identifier (nanoid)
• user_id / organization_id - Owner reference
• website_id - Optional website association
• name - Alarm name (required)
• description - Alarm description (optional)
• enabled - Boolean, whether alarm is active
• notification_channels - Array of channels (slack, discord, email, webhook, teams, telegram, google-chat)
• slack_webhook_url - Optional Slack webhook URL
• discord_webhook_url - Optional Discord webhook URL
• teams_webhook_url - Optional Teams webhook URL
• telegram_bot_token - Optional Telegram bot token
• telegram_chat_id - Optional Telegram chat ID
• google_chat_webhook_url - Optional Google Chat webhook URL
• email_addresses - Array of email addresses
• webhook_url - Optional custom webhook URL
• webhook_headers - JSON object for custom headers
• trigger_type - Type of trigger (uptime, traffic_spike, error_rate, goal, custom)
• trigger_conditions - JSON object for trigger conditions/thresholds
• created_at - Timestamp
• updated_at - Timestamp

Acceptance Criteria:

• Drizzle schema created in packages/db/src/drizzle/schema.ts
• Relations properly defined
• Migration runs successfully
• Indexes on user_id, organization_id, website_id, enabled

2. API Endpoints (Required)

Create ORPC endpoints for alarm CRUD operations.

Endpoints:

• alarms.list - List all alarms for user/organization
• alarms.get - Get single alarm by ID
• alarms.create - Create new alarm
• alarms.update - Update existing alarm
• alarms.delete - Delete alarm
• alarms.test - Send test notification to configured channels

Acceptance Criteria:

• All endpoints created in packages/rpc/src/routers/alarms.ts
• Proper Zod validation schemas
• Authorization checks (user can only access their own alarms)
• Test notification uses @databuddy/notifications package
• Proper error handling and responses

3. Dashboard UI (Required)

Create the alarms management UI in the dashboard settings.

Pages/Components:

• Settings → Notifications page with alarms list
• Create/Edit alarm modal or page
• Channel configuration (add Slack URL, Discord URL, Teams URL, Telegram bot token + chat ID, Google Chat URL, emails, webhook)
• Trigger type selection and condition configuration
• Test notification button
• Enable/disable toggle

Acceptance Criteria:

• UI matches existing dashboard design patterns
• Uses existing UI components (Button, Input, Select, Dialog, etc.)
• Mobile responsive
• Form validation with proper error messages
• Loading states and optimistic updates
• Success/error toasts using Sonner
• Uses Phosphor icons (not Lucide)

4. Testing (Required)

Acceptance Criteria:

• API endpoint tests in packages/rpc/src/routers/alarms.test.ts
• Test alarm creation, update, delete operations
• Test authorization (user cannot access others' alarms)
• Test validation (invalid webhook URLs, empty required fields)

Available Notification Channels

The @databuddy/notifications package supports 7 channels. Each has a helper function for one-off sends and a provider class for use with NotificationClient:

All helpers and providers support timeout, retries, and retryDelay options with exponential backoff.

Technical Requirements

• Follow existing codebase patterns and conventions
• Use bun for all package management (never npm/pnpm)
• TypeScript with strict types (no any, unknown, or never)
• Use dayjs for dates (never date-fns)
• Use Tanstack Query for data fetching hooks
• Use Jotai for any local state if needed
• Proper error boundaries
• Use rounded class (not rounded-xl or rounded-md)

Design Reference

The UI should match the existing dashboard design. Reference these for patterns:

• apps/dashboard/app/(main)/settings/ - Settings page patterns
• apps/dashboard/components/ - Existing component patterns
• Current notification settings page at apps/dashboard/app/(main)/settings/notifications/page.tsx (currently shows "Coming Soon")

Files to Reference

• packages/notifications/ - Notification providers and helpers
• packages/notifications/README.md - Full API reference and usage examples
• packages/db/src/drizzle/schema.ts - Database schema patterns
• packages/rpc/src/routers/ - API router patterns
• packages/validation/src/schemas/ - Validation schema patterns

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 the UI
• PR description explains implementation choices

Questions?

Comment on this issue for any clarification needed before starting.