PROJECT OVERVIEW:
The application, named 'Kesinti Bildirim Merkezi' (Outage Notification Hub), aims to solve the critical problem of service disruptions faced by developers, DevOps engineers, and IT professionals. Inspired by recent Hacker News discussions about GitHub outages, this platform will provide real-time, community-driven, and customizable alerts for critical service outages and maintenance. The core value proposition is to minimize downtime impact by providing timely and accurate notifications, allowing users to proactively manage their workflows and mitigate potential losses. It will aggregate official status updates with community-reported incidents for a comprehensive view.
TECH STACK:
- Frontend: React (using Create React App or Vite for setup)
- Styling: Tailwind CSS for rapid UI development and consistent styling.
- State Management: Zustand or Redux Toolkit for efficient global state management.
- Routing: React Router DOM for navigation within the single-page application.
- API Calls: Axios for handling HTTP requests.
- Form Handling: React Hook Form for efficient and reusable form management.
- Utility Libraries: Date-fns for date/time manipulation, potentially a library like `react-hot-toast` for notifications.
- Icons: Heroicons or similar SVG icon library.
- Deployment: Vercel or Netlify for seamless deployment.
CORE FEATURES:
1. **Service Status Dashboard**:
* **User Flow**: Upon login/landing, the user sees a dashboard displaying the current status (Operational, Degraded Performance, Partial Outage, Major Outage) of a pre-defined list of critical services (e.g., GitHub, AWS, Azure, Google Cloud, Slack). Each service card shows its name, logo, current status, and last updated time. Users can refresh the status. Admins can configure the list of monitored services.
* **Details**: Clicking a service card expands to show recent incidents, maintenance schedules, and official status page links.
2. **Customizable Alerts**:
* **User Flow**: Within their user settings or a dedicated 'Alerts' section, users can configure alerts. They select a service, choose the type of event (e.g., 'Outage', 'Maintenance', 'Performance Degradation'), and select notification methods (Email, SMS - if implemented and paid). They can also set priority levels.
* **Details**: The system needs to store these user preferences and trigger notifications based on incoming status updates or verified community reports.
3. **Real-time Notifications (Email/SMS)**:
* **User Flow**: When a monitored service experiences a relevant event (based on user's alert settings), the system instantly sends an email or SMS. The notification content includes the service name, event type, brief description, timestamp, and a link to the dashboard or official status page.
* **Details**: Email notifications can use a service like SendGrid or Mailgun. SMS requires integration with Twilio or similar, likely a premium feature.
4. **Community Incident Reporting**:
* **User Flow**: Users encountering an issue not yet officially reported or wanting to add context can click a 'Report Incident' button. A modal appears asking for the affected service, a brief description of the problem, and optionally, the time it started. The report is submitted for moderation.
* **Details**: Submitted reports go into a moderation queue. Admins or trusted users can verify reports. Verified reports can then trigger alerts for other users subscribed to that service and update the overall service status if necessary.
5. **Incident History**:
* **User Flow**: A dedicated 'History' or 'Incidents' page allows users to browse past outages and maintenance events. They can filter by service, date range, and event type.
* **Details**: This section displays a chronological list of resolved incidents with details about duration, impact, and resolution notes, sourced from official posts and community reports.
UI/UX DESIGN:
- **Layout**: A clean, single-page application layout. A fixed navigation sidebar (collapsible on smaller screens) for accessing Dashboard, Alerts, History, and Settings. The main content area displays the selected section.
- **Color Palette**: Primary: Deep Blue (#1e3a8a - Tailwind's `blue-900`) for headers, nav. Secondary: Teal/Green (#10b981 - Tailwind's `emerald-500`) for operational statuses and success messages. Warning/Outage: Orange/Red (#f59e0b - `amber-500` or #ef4444 - `red-500`). Neutral: Grays (from Tailwind's `gray-100` to `gray-800`) for backgrounds, text, borders. Accent: A slightly brighter blue or purple for interactive elements.
- **Typography**: Sans-serif font like Inter or Poppins for readability. Clear hierarchy using font weights (bold, semi-bold) and sizes.
- **Responsive Design**: Mobile-first approach. Sidebar collapses into a hamburger menu on mobile. Dashboard cards stack vertically. Forms and buttons are easily tappable. Use Tailwind's responsive prefixes (sm:, md:, lg:, xl:).
- **Components**: Cards for services, modals for reporting/settings, input fields, buttons, toggles, status indicators (colored dots/badges), notification toasts.
COMPONENT BREAKDOWN:
- `App.jsx`: Main wrapper, sets up routing, global layout.
- `Navbar.jsx`: Collapsible sidebar navigation. Props: `isOpen`, `onClose`, `links`. Responsibilities: Navigation links, user authentication status display.
- `DashboardPage.jsx`: Fetches and displays service status cards. Props: None (fetches data internally). Responsibilities: Orchestrates service card display, triggers data fetching.
- `ServiceCard.jsx`: Displays individual service status. Props: `service` (object with name, logo, status, lastUpdated), `onClick`. Responsibilities: Renders service info, visual status indicator.
- `AlertsPage.jsx`: Manages user alert configurations. Props: `userAlerts`, `availableServices`. Responsibilities: Form for creating/editing alerts, saving preferences.
- `AlertForm.jsx`: Form component for configuring alerts. Props: `services`, `initialData`, `onSubmit`. Responsibilities: Input fields for service, event type, notification method.
- `HistoryPage.jsx`: Displays list of past incidents. Props: `incidents` (array). Responsibilities: Renders incident list, filtering/sorting controls.
- `IncidentListItem.jsx`: Renders a single item in the incident history. Props: `incident` (object with service, type, startTime, endTime, description). Responsibilities: Displays incident details.
- `ReportIncidentModal.jsx`: Modal for community reporting. Props: `isOpen`, `onClose`, `onSubmit`, `services`. Responsibilities: Form for reporting an incident.
- `NotificationToast.jsx`: Reusable toast notification component. Props: `message`, `type` (success, error, info). Responsibilities: Display temporary feedback messages.
- `StatusIndicator.jsx`: Reusable component for visual status cues. Props: `status` (string). Responsibilities: Renders colored dot/badge based on status.
DATA MODEL:
- **Service Object**: `{ id: string, name: string, logoUrl: string, officialStatusPage: string, description: string }`
- **Incident Object**: `{ id: string, serviceId: string, type: 'outage' | 'maintenance' | 'degraded', startTime: Date, endTime: Date | null, reportedBy: 'official' | 'community', reportedByUserId: string | null, description: string, status: 'investigating' | 'identified' | 'resolved', severity: 'minor' | 'major' }`
- **User Alert Object**: `{ id: string, userId: string, serviceId: string, eventType: 'outage' | 'maintenance' | 'degraded', notificationMethods: ['email'] | ['sms'] | ['email', 'sms'], priority: 'high' | 'medium' | 'low' }`
- **State Structure (Zustand Example)**:
```javascript
{
services: { data: [], loading: false, error: null },
incidents: { data: [], loading: false, error: null },
userAlerts: { data: [], loading: false, error: null },
currentUser: { info: null, loading: false, error: null },
notifications: [], // For toasts
// ... other global states like UI themes, etc.
}
```
- **Local Storage**: Could be used for persisting user preferences like theme, last viewed section, or temporary state if offline capabilities were added.
ANIMATIONS & INTERACTIONS:
- **Page Transitions**: Subtle fade-in/fade-out between main sections using `react-transition-group` or similar.
- **Service Card Hover**: Slight scale-up or shadow increase on service card hover to indicate interactivity.
- **Button Interactions**: Subtle background color change or slight scale-down on button click.
- **Loading States**: Skeleton loaders or spinners on cards and lists while data is being fetched. `StatusIndicator` component might have a subtle pulse animation when initially loading.
- **Notification Toasts**: Appear smoothly from a corner (e.g., top-right) and fade out.
- **Sidebar Collapse/Expand**: Smooth sliding animation.
EDGE CASES:
- **Empty States**: Dashboard, Alerts, and History pages should have user-friendly messages and potential CTAs when no data is available (e.g., 'No alerts configured yet. Set up your first alert!', 'No past incidents recorded.').
- **Error Handling**: Network errors during data fetching should display informative error messages to the user, possibly via `NotificationToast`. Form submission errors should be clearly indicated next to the relevant fields.
- **Validation**: Alert configuration forms must validate inputs (e.g., service selected, event type chosen). Community reports need basic validation to prevent spam.
- **Authentication**: Handling of login/logout states, expired sessions. Guest users might see a limited view.
- **Notification Throttling**: Prevent excessive notifications for the same ongoing event unless its status changes significantly.
- **Accessibility (a11y)**: Use semantic HTML, ensure sufficient color contrast, provide keyboard navigation, use ARIA attributes where necessary, ensure focus management.
SAMPLE DATA:
1. **Service**: `{ id: 'github', name: 'GitHub', logoUrl: '/logos/github.svg', officialStatusPage: 'https://www.githubstatus.com/', description: 'Code hosting and collaboration platform.' }`
2. **Service**: `{ id: 'aws', name: 'AWS', logoUrl: '/logos/aws.svg', officialStatusPage: 'https://status.aws.amazon.com/', description: 'Cloud computing web services.' }`
3. **Incident (Official)**: `{ id: 'inc-123', serviceId: 'github', type: 'outage', startTime: '2023-10-27T10:00:00Z', endTime: '2023-10-27T11:30:00Z', reportedBy: 'official', reportedByUserId: null, description: 'API rate limiting and authentication failures impacting core services.', status: 'resolved', severity: 'major' }`
4. **Incident (Community)**: `{ id: 'inc-124', serviceId: 'aws', type: 'degraded', startTime: '2023-10-27T14:15:00Z', endTime: null, reportedBy: 'community', reportedByUserId: 'user-xyz', description: 'S3 bucket access extremely slow in us-east-1 region.', status: 'investigating', severity: 'minor' }`
5. **User Alert**: `{ id: 'alert-abc', userId: 'user-xyz', serviceId: 'github', eventType: 'outage', notificationMethods: ['email'], priority: 'high' }`
6. **User Alert**: `{ id: 'alert-def', userId: 'user-xyz', serviceId: 'aws', eventType: 'degraded', notificationMethods: ['email', 'sms'], priority: 'medium' }`
7. **Dashboard State (Example)**: `services: { data: [ { id: 'github', name: 'GitHub', status: 'degraded', lastUpdated: '2023-10-27T15:05:00Z', logoUrl: '/logos/github.svg' }, { id: 'aws', name: 'AWS', status: 'operational', lastUpdated: '2023-10-27T15:00:00Z', logoUrl: '/logos/aws.svg' } ], loading: false, error: null }`
8. **Notification Toast**: `{ id: 'toast-1', message: 'GitHub outage resolved.', type: 'success' }`
DEPLOYMENT NOTES:
- **Environment Variables**: Use `.env` files. Key variables: `REACT_APP_API_URL` (for backend API), `REACT_APP_ENABLE_SMS` (boolean flag for SMS feature), `REACT_APP_MAIL_API_KEY` (for email service).
- **Build Command**: Standard build command for the chosen framework (e.g., `npm run build` for CRA, `npm run build` for Vite).
- **Hosting**: Deploy to Vercel or Netlify for CI/CD integration, automatic HTTPS, and global CDN.
- **Performance**: Code splitting using React.lazy/Suspense for large components. Image optimization for logos. Memoization (`React.memo`, `useMemo`, `useCallback`) to prevent unnecessary re-renders. Minimize bundle size.
- **API Backend**: A simple backend API (Node.js/Express, Python/Flask, or a serverless function) will be required to fetch official statuses, manage community reports, handle user authentication, and trigger notifications. This prompt focuses on the frontend, but the backend contract (API endpoints, expected data formats) should be clearly defined.