You are a senior full-stack developer tasked with creating a single-page application (SPA) that monitors GitHub's service availability and performance. The application should provide real-time status updates, historical data analysis, and proactive alerts to developers and DevOps teams.
**1. PROJECT OVERVIEW:**
The application aims to solve the problem of unreliable GitHub service availability, which significantly impacts developer productivity and project timelines. It will offer a centralized dashboard to track the status of critical GitHub services like Actions, Pull Requests, Notifications, and Copilot. The core value proposition is to provide developers with timely insights into GitHub's performance, enabling them to anticipate issues, mitigate disruptions, and maintain their development workflow with minimal interruption. This tool acts as an early warning system and a historical performance analyzer for GitHub services.
**2. TECH STACK:**
- **Frontend Framework:** React (using Create React App or Vite for setup)
- **Styling:** Tailwind CSS for rapid UI development and consistent design.
- **State Management:** Zustand or Redux Toolkit for efficient global state management.
- **API Client:** Axios for making HTTP requests to a potential backend or external status APIs.
- **Charting Library:** Chart.js or Recharts for visualizing historical uptime data.
- **Routing:** React Router DOM for navigation within the SPA.
- **Alerting/Notifications:** Browser notifications API and potential integration points for email/Slack (backend dependent).
- **Local Storage:** For persisting user preferences and alert settings.
**3. CORE FEATURES:**
- **Real-time Service Monitoring Dashboard:**
- **User Flow:** Upon loading the app, the dashboard displays the current status of key GitHub services (e.g., Actions, Pull Requests, Copilot, Issues, Pages). Each service is represented by a card showing its name, current status (Operational, Degraded, Major Outage), and a timestamp of the last update.
- **Detail:** Cards should use distinct colors for statuses (e.g., green for Operational, yellow for Degraded, red for Major Outage). Hovering over a card could reveal more details like the duration of the current status or a brief description from GitHub's status page.
- **Historical Uptime Analysis:**
- **User Flow:** Users can navigate to a 'History' or 'Reports' section. They can select a service and a time range (e.g., last 7 days, 30 days, 90 days). The application displays a chart showing the uptime percentage and incidents over the selected period.
- **Detail:** This feature requires fetching historical data (potentially from a dedicated backend or by scraping/parsing GitHub's historical status page if feasible and ethical). The chart should clearly indicate periods of downtime and their severity.
- **Customizable Alerts:**
- **User Flow:** In a 'Settings' or 'Alerts' section, users can choose which GitHub services to monitor and set specific thresholds for receiving notifications (e.g., notify me if 'Actions' is 'Degraded' for more than 15 minutes, or if 'Copilot' has a 'Major Outage'). Users can configure notification methods (in-app, browser notification, potentially email/Slack via backend).
- **Detail:** This involves managing user preferences in state or local storage. Alert logic will trigger based on incoming status updates and user-defined rules.
- **Incident Feed:**
- **User Flow:** A dedicated section lists recent incidents reported by GitHub, including timestamps, affected services, and descriptions.
- **Detail:** This can be populated from GitHub's official status updates, requiring a mechanism to fetch and display this information.
**4. UI/UX DESIGN:**
- **Layout:** Single-page application with a main navigation sidebar (or top bar) linking to Dashboard, History/Reports, and Settings. The main content area displays the selected section.
- **Color Palette:** Primary colors: Dark grey/black for background (developer aesthetic), accent colors: Green (operational), Yellow (degraded), Red (outage), Blue (interactive elements/links). Use Tailwind's default palette as a base and customize.
- **Typography:** Clean, readable sans-serif font (e.g., Inter, Roboto). Use varying font weights and sizes for hierarchy.
- **Responsive Design:** Mobile-first approach. Ensure usability on various screen sizes using Tailwind's responsive modifiers (sm:, md:, lg:). The dashboard should adapt gracefully, perhaps stacking service cards vertically on smaller screens.
- **Component Hierarchy:** Dashboard -> ServiceCard, StatusIndicator, Chart. History -> DateRangePicker, ChartComponent. Settings -> AlertRuleForm, NotificationPreferenceToggle.
**5. DATA MODEL:**
- **Service Status Object:**
```json
{
"id": "string", // e.g., "actions", "copilot"
"name": "string", // e.g., "GitHub Actions"
"status": "operational" | "degraded" | "major_outage",
"lastUpdated": "string" // ISO 8601 timestamp
"description": "string" // Optional: brief description from status page
}
```
- **Incident Object:**
```json
{
"id": "string",
"startTime": "string", // ISO 8601 timestamp
"endTime": "string", // ISO 8601 timestamp or null if ongoing
"serviceIds": ["string"], // Array of affected service IDs
"severity": "major" | "minor",
"message": "string"
}
```
- **User Preferences/Alerts:**
```json
{
"alertEnabled": boolean,
"alertThresholdMinutes": number, // e.g., 15
"alertServices": ["string"] // Array of service IDs to monitor
"notificationMethod": "browser" | "email" | "slack" // simplified for prompt
}
```
- **State Management:** Store the current status of all services, historical data, and user preferences in the global state.
**6. COMPONENT BREAKDOWN:**
- **`App.js` / `App.tsx`:** Main application component, sets up routing and global context/store providers.
- **`DashboardPage.js`:** Parent component for the dashboard view. Fetches and displays service statuses.
- **`ServiceCard.js`:** Displays information for a single GitHub service. Props: `service` (Service Status Object).
- **`StatusIndicator.js`:** Visual indicator for service status (colored dot/badge). Props: `status`.
- **`IncidentFeed.js`:** Displays a list of recent incidents. Props: `incidents` (array of Incident Objects).
- **`HistoryPage.js`:** Parent component for the historical analysis view.
- **`DateRangePicker.js`:** Component to select the time range for reports. Props: `onChange`.
- **`UptimeChart.js`:** Displays the uptime chart using a charting library. Props: `data`, `serviceId`.
- **`SettingsPage.js`:** Parent component for the settings/alert configuration view.
- **`AlertRuleForm.js`:** Form to configure alert rules for a service. Props: `services`, `currentRule`, `onSave`.
- **`NotificationPreferenceToggle.js`:** Toggles for notification methods. Props: `method`, `isChecked`, `onChange`.
- **`Header.js`:** Top navigation bar or header component.
- **`Sidebar.js`:** Navigation menu component.
**7. ANIMATIONS & INTERACTIONS:**
- **Loading States:** Use subtle shimmer/skeleton loaders for cards and charts while data is being fetched. Spinner components for ongoing operations.
- **Transitions:** Smooth transitions for status changes on the dashboard (e.g., fade in/out, slight scale animation). Route transitions using libraries like `Framer Motion` or `React Transition Group` for a polished feel.
- **Hover Effects:** Subtle background color changes or slight scaling on interactive elements (buttons, cards) on hover.
- **Micro-interactions:** Visual feedback on button clicks, form submissions.
**8. EDGE CASES:**
- **Empty States:** Display friendly messages and clear calls to action when no services are monitored, no historical data is available, or no incidents are reported.
- **Error Handling:** Gracefully handle API errors (e.g., network issues, server errors). Display informative error messages to the user. Implement retry mechanisms where appropriate.
- **Validation:** Client-side validation for alert thresholds (e.g., must be a positive number) and other form inputs.
- **Accessibility (a11y):** Use semantic HTML, provide ARIA attributes where necessary, ensure sufficient color contrast, and make the application navigable via keyboard.
- **Data Fetching Issues:** If GitHub's status page structure changes, the data scraping/fetching logic might break. Implement robust error handling and potentially fallback mechanisms.
- **Timezones:** Ensure all timestamps are handled consistently, preferably in UTC, and displayed in the user's local timezone.
**9. SAMPLE DATA:**
- **Mock Service Statuses:**
```json
[
{
"id": "actions",
"name": "GitHub Actions",
"status": "operational",
"lastUpdated": "2023-10-27T10:30:00Z",
"description": "All systems operational."
},
{
"id": "copilot",
"name": "GitHub Copilot",
"status": "degraded",
"lastUpdated": "2023-10-27T10:45:00Z",
"description": "Intermittent issues with model availability for some users."
},
{
"id": "pull-requests",
"name": "Pull Requests",
"status": "operational",
"lastUpdated": "2023-10-27T10:50:00Z",
"description": null
}
]
```
- **Mock Incidents:**
```json
[
{
"id": "inc_123",
"startTime": "2023-10-26T14:00:00Z",
"endTime": "2023-10-26T16:30:00Z",
"serviceIds": ["actions", "issues"],
"severity": "major",
"message": "High latency experienced across GitHub Actions and Issues services due to unexpected traffic surge."
},
{
"id": "inc_124",
"startTime": "2023-10-27T09:00:00Z",
"endTime": null,
"serviceIds": ["copilot"],
"severity": "minor",
"message": "Policy propagation delays affecting new Copilot model availability."
}
]
```
- **Mock Historical Data (for Charting):**
```json
// Represents data points for a specific service over time
[
{"timestamp": "2023-10-26T00:00:00Z", "status": "operational"},
{"timestamp": "2023-10-26T06:00:00Z", "status": "operational"},
{"timestamp": "2023-10-26T12:00:00Z", "status": "operational"},
{"timestamp": "2023-10-26T18:00:00Z", "status": "major_outage"}, // Incident starts
{"timestamp": "2023-10-27T00:00:00Z", "status": "major_outage"},
{"timestamp": "2023-10-27T06:00:00Z", "status": "degraded"}, // Incident resolution/degradation
{"timestamp": "2023-10-27T10:45:00Z", "status": "degraded"}
]
```
- **Mock User Preferences:**
```json
{
"alertEnabled": true,
"alertThresholdMinutes": 15,
"alertServices": ["actions", "copilot"],
"notificationMethod": "browser"
}
```
**10. DEPLOYMENT NOTES:**
- **Build:** Use standard build commands for the chosen framework (e.g., `npm run build` or `yarn build`).
- **Environment Variables:** Manage API keys (if any), base URLs, and feature flags using environment variables (e.g., `REACT_APP_API_URL`). Use a `.env` file for local development.
- **Hosting:** Can be deployed on static hosting platforms like Vercel, Netlify, or GitHub Pages. For features requiring a backend (e.g., email/Slack alerts, persistent historical data storage), consider platforms like Heroku, AWS, or Google Cloud.
- **Performance Optimizations:** Code splitting, lazy loading components, optimizing image assets, efficient state management, and memoization (React.memo, useMemo) are crucial for a smooth user experience, especially on the dashboard and history pages. Ensure efficient data fetching strategies to avoid overwhelming the browser or any potential backend services.
- **Data Source:** The primary challenge is reliably obtaining GitHub's service status and historical data. This might involve parsing their official status page (https://www.githubstatus.com/), using an unofficial API if available, or building a backend service that scrapes and aggregates this data reliably. The prompt assumes the frontend can access this data, but a real-world implementation would likely need a backend component for robustness and to comply with terms of service.