You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 27, 2024. It is now read-only.
To get things started, let's setup the initial system for incident handling: events. Events will be used for reactive type incidents along with maintenance plans.
Scope out the database schema for events
Build in migration support for FastAPI with Alchemy
Write the endpoints with mock data support
Build the rough initial events look in the client
The text was updated successfully, but these errors were encountered:
Still got a ways to go, but this is the first take on the database schema. It's funny, I started with just events and before you know it, there's an entire section of tables just for this. Here's the breakdown as I see it now:
events will be the container for any public incident type (incident or maintenance)
updates will contain the details and timeline
milestones will be each step in the event (e.g. Maintenance In Progress or Identified the Issue)
statuses are the critical impacts of the connections (e.g. Major Outage or Degraded Performance)
I want users to be able to override the naming conventions per page for these labels, hence the reason for the overrides.
To get things started, let's setup the initial system for incident handling: events. Events will be used for reactive type incidents along with maintenance plans.
The text was updated successfully, but these errors were encountered: