Build an Incident Command Center with AI

Design and deploy a real-time incident management dashboard using Bolt.new.

Introduction

30 Second Summary

When a production service goes down, the difference between a 5-minute fix and a 5-hour outage often comes down to one thing: visibility. Engineering teams rely on incident command centers to see exactly what's broken, who's working on it, and what stage the fix is at.

In this project, you will build a real-time Incident Command Center dashboard using an architecture-first AI workflow. You'll design the system first, then use Bolt.new to turn your design into a deployed web app without writing any code yourself.

What You'll Build

A full-stack Incident Command Center with a database, incident state machine, severity-based filtering, live dashboard metrics, and search functionality.

By the end of this project, you'll have:

A data model document that serves as your architecture spec, written in plain English.
A working Incident Command Center web app with a database, status workflows, live metrics, and search/filter functionality.
A live deployed URL you can share with anyone, hosted for free on Bolt.new.
Secret Mission: Add a post-mortem report generator that summarizes resolved incidents into a timeline view.

Are there any prerequisites?

None. You only need a web browser and an email address. Everything in this project runs in the browser at bolt.new. No code editor, terminal, or installation required.

Set Up Your Bolt.new Account

Bolt.new is the AI-powered builder that will turn your architecture into a working app. You describe what you want, and Bolt writes the code, creates the database, and deploys everything for you.

In this step, you will create your free Bolt.new account and learn the editor interface. Knowing where the key controls live will save you time once you start building.

In this step, get ready to:

Create your free Bolt.new account.
Explore the editor interface and understand your token budget.
Learn where Project Knowledge lives for a future step.

Create your free Bolt.new account

Bolt.new runs entirely in your browser. There is nothing to install.

Open a new browser tab and go to https://bolt.new/pricing.
Find the Free plan ($0) and click Get started.
Sign up using Google, GitHub, or email. No credit card is required.
Complete the onboarding survey that appears after sign-up.

What is Bolt.new?

Bolt.new is an AI coding agent that builds full-stack web apps from text prompts. You describe what you want in plain English, and Bolt generates the code, creates databases, and deploys your project to a live URL.

Everything happens inside your browser. No terminal, no code editor, no local files.

Can't find the sign-up page?

Make sure you are on bolt.new/pricing (not bolt.com or a similar domain). The Get started button sits directly under the Free plan column.

help me find the Bolt.new free plan sign-up page

Explore the interface and understand your token budget

After signing in, Bolt drops you into its editor. Before you start building, take a moment to locate the controls you will use throughout this project.

Locate the chatbox at the bottom of the screen. This is where you type prompts to tell Bolt what to build.
Find the Plan/Build toggle in the bottom-right corner of the chatbox. Plan Mode outlines what Bolt will do without writing code. Build Mode executes and generates code.
Find the plus icon in the bottom-left corner of the chatbox. This gives you access to Enhance prompt and the Prompt Library.
Check your token counter. On the free plan, you have 1 million tokens per month and a 300,000 token daily limit.

What are tokens?

Tokens are the currency Bolt uses to measure AI work. Every prompt you send and every line of code Bolt generates consumes tokens. Most of the token usage comes from syncing your project files to the AI.

A full app build (with a database and authentication) uses roughly 200,000 tokens. Your daily limit of 300,000 tokens means you can build significant features each day without running out.

Save tokens with Plan Mode

Plan Mode uses fewer tokens than Build Mode because it outlines the work without generating code. Always start with Plan Mode for complex features, then switch to Build Mode to execute.

Learn where Project Knowledge lives

Bolt has a feature called Project Knowledge. It stores persistent instructions that guide every response Bolt generates inside a project.

You will not use this feature yet (you need a project and an architecture spec first).
For now, know that it lives in Project settings under the Knowledge section.
In Step 3, you will paste your architecture document here so Bolt references it on every prompt.

Why use Project Knowledge?

Without Project Knowledge, Bolt treats each prompt as a standalone request. It might build features that contradict your data model or ignore your component structure.

By pasting your architecture spec into Project Knowledge, every response Bolt generates aligns with your design decisions. This is what keeps large projects coherent across many prompts.

Your Bolt.new account is ready. Next up, you will design the architecture for your Incident Command Center before asking the AI to build anything.

Design Your Architecture

Your Bolt.new account is set up and ready to go. Now comes the most important part of the entire project.

You are going to design your entire system in plain English before asking the AI to write a single line of code. This architecture-first approach gives Bolt a clear blueprint to follow. Without it, AI tools generate random features that don't fit together.

In this step, get ready to:

Define your data model with entities, fields, and relationships.
Map out your component tree (what the user sees on screen).
Design the state machine (how incidents flow through statuses).

Why design before prompting?

When you give an AI tool a vague prompt like "build me a dashboard," it guesses at your data structure, invents random fields, and produces something that breaks the moment you try to add features.

By writing a spec first, you turn the AI into an executor of your vision instead of a random generator. Every prompt you send in later steps will reference this document, keeping the AI aligned with your design.

Define your data model

A data model describes the "things" in your system and how they relate to each other. For an Incident Command Center, the core things are incidents, the services they affect, the teams that respond, and the timeline of events.

Open any text editor on your computer (Notepad on Windows, TextEdit on macOS, or any app you prefer).
Type out the following data model. This defines every entity your app will store:

Data Model:
- Incident: id, title, description, severity (critical/high/medium/low), status (triggered/acknowledged/investigating/resolved), created_at, updated_at, assigned_team, assigned_service
- Service: id, name, status (healthy/degraded/down), last_incident_at
- Team: id, name, on_call_member
- TimelineEvent: id, incident_id, event_type (status_change/note/escalation), description, created_at, created_by

Relationships:
- An Incident belongs to one Service
- An Incident belongs to one Team
- An Incident has many TimelineEvents
- A Service has many Incidents

What does this data model describe?

Each entity represents a database table that Bolt will create for you. The fields inside parentheses are enums (fixed options). For example, severity can only be one of four values: critical, high, medium, or low.

The relationships section tells the AI how entities connect. "An Incident belongs to one Service" means every incident is linked to exactly one service. "A Service has many Incidents" means a single service can have multiple incidents over time.

Confirm you have 4 entities listed (Incident, Service, Team, TimelineEvent) and 4 relationship statements below them.

Define your component tree

A component tree maps out every screen and UI element in your app as a hierarchy. It tells the AI exactly what to build visually, so it doesn't guess or invent screens you don't want.

Below your data model, add a blank line and type out this component tree:

Component Tree:
- App Layout
  - Sidebar (navigation: Dashboard, Incidents, Services)
  - Main Content Area
    - Dashboard View
      - Metrics Bar (open incidents count, MTTR, incidents by severity)
      - Active Incidents List (sorted by severity)
      - Service Health Grid
    - Incidents View
      - Filter Bar (status, severity, team, date range)
      - Incidents Table (sortable columns)
      - Incident Detail Panel (timeline, status transitions, notes)
    - Services View
      - Service Cards (name, status indicator, recent incidents)

What does the component tree tell the AI?

The indentation shows nesting. The Sidebar and Main Content Area both live inside the App Layout. Dashboard View, Incidents View, and Services View are different "pages" inside the Main Content Area.

The parenthetical notes (like "sorted by severity") give the AI specific behaviour instructions. Without them, the AI would make its own decisions about sorting, filtering, and display.

Confirm your component tree starts with App Layout at the top and branches into Sidebar and Main Content Area, with three views nested inside.

Define your state machine

A state machine defines the allowed transitions between statuses. Without one, the AI might let an incident jump from "resolved" back to "triggered," which makes no sense in real operations.

Below your component tree, add a blank line and type out these status transition rules:

State Machine:
- Triggered -> Acknowledged (someone sees it)
- Triggered -> Investigating (skip acknowledge, jump to investigation)
- Acknowledged -> Investigating (start working on it)
- Investigating -> Resolved (fix confirmed)
- Any state -> Resolved (emergency close)

Why define allowed transitions?

The state machine prevents impossible workflows. An incident can only move forward through these defined paths. The "Any state -> Resolved" rule is an escape hatch for emergencies where the team needs to force-close an incident immediately.

When you give this to Bolt, it will generate buttons that only allow valid transitions. A "Resolved" incident won't show a button to go back to "Triggered."

Confirm you have 5 transition rules listed, with the last one being the emergency-close rule.
Save your text file. You now have a complete architecture spec.

✔️ Awesome, I've got everything!

Great. Make sure you've saved the file. You'll copy and paste from this document in the next step.

ⓧ I'd like to double check the full document

Here is the complete architecture spec. Your document should have all three sections:

Data Model:
- Incident: id, title, description, severity (critical/high/medium/low), status (triggered/acknowledged/investigating/resolved), created_at, updated_at, assigned_team, assigned_service
- Service: id, name, status (healthy/degraded/down), last_incident_at
- Team: id, name, on_call_member
- TimelineEvent: id, incident_id, event_type (status_change/note/escalation), description, created_at, created_by

Relationships:
- An Incident belongs to one Service
- An Incident belongs to one Team
- An Incident has many TimelineEvents
- A Service has many Incidents

Component Tree:
- App Layout
  - Sidebar (navigation: Dashboard, Incidents, Services)
  - Main Content Area
    - Dashboard View
      - Metrics Bar (open incidents count, MTTR, incidents by severity)
      - Active Incidents List (sorted by severity)
      - Service Health Grid
    - Incidents View
      - Filter Bar (status, severity, team, date range)
      - Incidents Table (sortable columns)
      - Incident Detail Panel (timeline, status transitions, notes)
    - Services View
      - Service Cards (name, status indicator, recent incidents)

State Machine:
- Triggered -> Acknowledged (someone sees it)
- Triggered -> Investigating (skip acknowledge, jump to investigation)
- Acknowledged -> Investigating (start working on it)
- Investigating -> Resolved (fix confirmed)
- Any state -> Resolved (emergency close)

Extra for Experts: Why not just let the AI figure this out?

AI tools like Bolt.new are excellent at generating code, but they cannot hold a consistent system design across many prompts unless you give them one. Each new prompt is a fresh conversation. Your architecture spec acts as the persistent memory that keeps every generated feature aligned with the same data structures and UI layout.

Your architecture blueprint is ready. Next up, you'll feed this spec to Bolt and watch it build a fully functional dashboard from your design.

Build the Foundation with AI

Your architecture spec is complete. You have a blueprint that defines exactly what your app needs: the data it stores, the screens users see, and the rules governing how incidents flow through the system.

Now you will hand this blueprint to Bolt.new's AI and let it build the foundation. You will use Plan Mode to validate the approach first, saving tokens by confirming the AI understands your architecture before it generates any code.

In this step, get ready to:

Use Plan Mode to validate your architecture with the AI.
Build a dark-themed dashboard skeleton with sidebar navigation and placeholder metrics.
Store your architecture spec in Project Knowledge for future prompts.

Start in Plan Mode and paste your architecture spec

Plan Mode lets you discuss your build with the AI before it writes any code. It uses fewer tokens than Build Mode and helps you confirm that Bolt understands your architecture before spending tokens on code generation.

In the Bolt.new chatbox, click Plan in the bottom-right corner of the chatbox. It highlights blue when active.
Paste the following prompt into the chatbox, replacing the placeholder with your full architecture spec from Step 2:

Build an Incident Command Center web app. Here is my architecture:

[[ARCHITECTURE_SPEC="your entire data model, component tree, and state machine from Step 2"]]

Start with the App Layout, Sidebar navigation, and the Dashboard View with the Metrics Bar showing placeholder data. Use a dark theme with a professional look suitable for an operations center. Include a database for incidents and services.

What does this prompt do?

The first line tells Bolt what you are building at a high level. Your pasted architecture spec gives Bolt the exact data model, component structure, and state machine rules to follow.

The last two lines scope this first build to just the foundation: layout, sidebar, dashboard skeleton, and database. You are not building everything at once.

Submit the prompt. Bolt responds with a plan in the chat.
Review the plan Bolt generates. Confirm it mentions your data model entities (Incident, Service, Team, TimelineEvent) and the sidebar navigation structure.
Click the Implement this plan quick action button that appears at the end of Bolt's response.

What is Plan Mode?

Plan Mode lets you have a back-and-forth discussion with the AI before it writes any code. When you click Implement this plan, Bolt automatically switches to Build Mode and starts generating the actual code.

This two-step approach prevents wasted tokens on code that misses your intent. You validate first, then build.

Test and validate the foundation

Wait for Bolt to finish building. This typically takes 2-5 minutes.
Check the preview panel on the right side of the screen.

You should see a dark-themed dashboard with a sidebar showing Dashboard, Incidents, and Services links, a metrics bar at the top, and placeholder content in the main area.

Preview not showing what you expected?

If the sidebar is missing a navigation item, describe the specific issue in the chatbox (e.g., "The sidebar is missing the Services navigation item").
If the theme is light instead of dark, prompt: "Change the theme to a dark professional look suitable for an operations center."
Bolt responds to specific, focused corrections better than vague requests like "fix it."

My Bolt.new preview does not match what I expected after using Plan Mode. How do I write a correction prompt?

Add your architecture spec to Project Knowledge

Project Knowledge stores persistent instructions that Bolt references on every future prompt. Adding your architecture spec here means Bolt will stay aligned with your data model and component tree automatically.

Click the gear icon in the top center of your screen.
Click All project settings.
In the left menu, click Knowledge.
Paste your full architecture spec (all three sections: Data Model, Component Tree, and State Machine) into the text field.
Click Save Prompt.

Why store the spec in Project Knowledge?

Without Project Knowledge, each new prompt starts from scratch. Bolt might forget your data model or invent new fields that contradict your design.

With your spec stored here, every response aligns with your architecture. This is what keeps the AI on track as your project grows across multiple prompts.

Your foundation is built and your architecture is locked in. Next up, you will build the incident management system with state machine logic that controls how incidents flow from triggered to resolved.

Build the Incident Management System

Your dashboard skeleton is live with navigation and placeholder data. Now it is time to bring it to life with the core functionality that makes an Incident Command Center actually useful.

In this step, you will build the incident management workflow. This means creating incidents, transitioning them through status stages using your state machine, tracking changes on a timeline, and wiring the Dashboard to display real data from your database.

In this step, get ready to:

Build the Incidents View with a table, create-incident form, and state machine logic.
Add the Incident Detail Panel with a timeline of status changes and notes.
Wire up the Dashboard to show live metrics from your database.

Add the Incidents View with state machine logic

The Incidents View is the operational heart of your app. It displays all incidents in a table, lets operators create new ones, and enforces your state machine rules for status transitions.

Make sure Plan is NOT highlighted blue in the bottom-right corner of the chatbox. You want Build mode for this prompt so Bolt writes actual code.
Paste the following prompt into the chatbox and submit it:

Add the Incidents View. Include:
1. A table showing all incidents with columns: Title, Severity (color-coded badges), Status, Service, Team, Created At
2. A button to create new incidents with a form (title, description, severity dropdown, service dropdown, team dropdown)
3. Status transition buttons on each incident that follow my state machine rules: Triggered can go to Acknowledged or Investigating. Acknowledged can go to Investigating. Investigating can go to Resolved. Any state can go to Resolved.
4. Store all incidents in the database.
Do not change the Dashboard or Sidebar.

What does this prompt do?

This prompt tells Bolt to build an entire CRUD interface for incidents. The key detail is the state machine constraint in point 3.

By specifying which transitions are allowed (Triggered to Acknowledged or Investigating, Acknowledged to Investigating, etc.), Bolt will generate logic that only shows valid transition buttons for each incident's current status. The "Do not change" line protects the work you already built.

Wait for Bolt to finish building (this may take 2-5 minutes).
In the preview, click Incidents in the sidebar.
Click the button to create a new incident. Fill in a title, select a severity, pick a service and team, then save it.
You should see the new incident appear in the table with a color-coded severity badge and status transition buttons.
Click a status transition button (e.g., Acknowledge) and confirm the status changes.

Don't see the Incidents View?

Check the preview panel on the right side of the screen. If it shows a loading spinner, wait for the build to complete.
If you see an error in the preview, describe the error in the chatbox (e.g., "I see a white screen when I click Incidents") and Bolt will fix it.
If the sidebar does not have an Incidents link, tell Bolt: "The Incidents navigation item is missing from the sidebar."

Help me troubleshoot my Incidents View not showing up in Bolt.new

Add the timeline and incident detail panel

Operators need to see the full history of an incident: every status change, every note added, and when each event happened. The Incident Detail Panel provides this timeline view.

In the chatbox (still in Build mode), paste the following prompt and submit it:

Add an Incident Detail Panel that opens when you click an incident in the table. It should show:
1. The incident title, description, severity, and current status
2. A timeline of all status changes with timestamps (stored as TimelineEvents in the database)
3. The ability to add notes to the timeline
4. Status transition buttons that create TimelineEvent entries when clicked
Do not change the Incidents table or Dashboard.

What does this prompt do?

This prompt builds a detail panel that opens on row click. Every time you transition an incident's status or add a note, a TimelineEvent record is created in the database with a timestamp.

This is the same pattern used at Google and Amazon for incident post-mortems. The timeline becomes an audit trail showing exactly what happened and when.

Wait for Bolt to finish building.
Click an incident row in the Incidents table. You should see the detail panel open with the incident's title, description, severity, and status.
Click a status transition button inside the detail panel. The timeline should update with a new entry showing the status change and a timestamp.
Add a note using the note input field. The note should appear in the timeline.

Timeline not updating?

If clicking an incident does nothing, tell Bolt: "Clicking an incident row does not open the detail panel."
If the timeline is empty after a status transition, tell Bolt: "Status transitions are not creating TimelineEvent entries in the database."
If you see duplicate entries, try refreshing the preview and testing again.

Help me fix my incident timeline in Bolt.new

Wire up the Dashboard metrics

Your Dashboard currently shows placeholder numbers. Now that incidents exist in the database, you can connect the Dashboard to display real, live data.

In the chatbox, paste the following prompt and submit it:

Update the Dashboard View to show real data from the database:
1. Metrics Bar: total open incidents (not resolved), incidents by severity (critical/high/medium/low counts), and average time to resolve for resolved incidents
2. Active Incidents List: show the 5 most recent non-resolved incidents sorted by severity (critical first)
3. Service Health Grid: show all services with a green/yellow/red status indicator based on whether they have active incidents
All data should come from the database. Do not change the Incidents View.

What does this prompt do?

This prompt turns your Dashboard from a static skeleton into a live operations center. The Metrics Bar aggregates data across all incidents. The Active Incidents List prioritizes by severity so critical issues are always visible first.

The Service Health Grid uses a traffic-light pattern (green/yellow/red) that operations teams scan at a glance. If a service has any active incident, its indicator changes color.

Wait for Bolt to finish building.
Click Dashboard in the sidebar.
Verify the Metrics Bar shows real numbers: total open incidents, a breakdown by severity, and average resolution time.
Check that the Active Incidents List shows your non-resolved incidents sorted with critical severity first.
Confirm the Service Health Grid shows services with colored status indicators (green for healthy, yellow or red for services with active incidents).

Create more test data

To see the Dashboard come alive, go back to the Incidents View and create 3-4 more incidents with different severities and services. Then return to the Dashboard and watch the metrics update.

Dashboard still showing placeholder data?

If the Metrics Bar shows zeros or placeholder text, tell Bolt: "The Dashboard metrics are not pulling real data from the database. They still show placeholder values."
If the Service Health Grid shows all services as the same color, make sure you have incidents assigned to different services. Then tell Bolt: "The Service Health Grid is not changing color based on active incidents."
If you accidentally changed the Incidents View, use Version History to restore a previous state without spending tokens.

Help me fix my Dashboard metrics in Bolt.new

Your incident management system is fully operational. You can create incidents, transition them through every stage of your state machine, track changes on a timeline, and see everything reflected in live Dashboard metrics. Next up, you will add search, filtering, and polish to make it production-ready.

Add Search, Filtering, and Polish

Your Incident Command Center now tracks incidents through their full lifecycle and shows real-time metrics on the Dashboard.

But finding a specific incident means scrolling through the entire table. There is also a Services View missing from your sidebar navigation. In this step, you will add powerful search and filtering, build the Services View, and deploy your finished app live to the internet.

In this step, get ready to:

Add a filter bar with real-time search, dropdown filters, and a date range picker.
Build the Services View with health status cards and manual status controls.
Polish the UI and deploy your app live to a public URL.

Add the filter and search system

Right now, if your ops team has 50 active incidents, there is no way to narrow the list. A real operations center needs instant filtering by status, severity, and team to surface what matters.

Make sure you are in Build mode (check the toggle in the bottom-right corner of the chatbox).
Paste the following prompt into the chatbox and press Enter to add the filter system:

Add a Filter Bar to the Incidents View with:
1. A search input that filters incidents by title (real-time as you type)
2. Dropdown filters for: Status (all/triggered/acknowledged/investigating/resolved), Severity (all/critical/high/medium/low), Team (all plus each team name)
3. A date range picker that filters by created_at
4. Filters should combine (AND logic). Show a count of results.
Do not change the Dashboard or Incident Detail Panel.

What does this prompt do?

This prompt asks Bolt.new to add five filter mechanisms that work together. The "AND logic" instruction means all active filters combine to narrow results (e.g., showing only critical incidents assigned to the Platform team that are still in the Investigating state).

The "Do not change" line at the end is critical for token efficiency. It prevents Bolt from accidentally rewriting views you already finished.

Wait for Bolt to finish building (1-3 minutes).
In the preview, navigate to the Incidents view from the sidebar.
You should see a Filter Bar above the incidents table with a search input, dropdown menus, and a date picker.
Test by typing part of an incident title into the search field. The table should filter in real time as you type.
Select a specific severity from the dropdown and confirm the table narrows to only matching incidents.

Filters not showing or not working?

If the Filter Bar does not appear, check the preview is on the Incidents view (not the Dashboard). If filters appear but do not narrow results, tell Bolt: "The severity filter is not filtering the incidents table. Make sure it queries the database with the selected filter value."

If Bolt made unwanted changes to your Dashboard, use Version History to revert and try again with the same prompt.

Help me debug my Bolt.new filter bar that isn't filtering incidents correctly.

Add the Services View

Your architecture spec defined a Services View with cards showing each service's health status. This gives ops teams a quick visual map of which services are healthy and which are in trouble.

Paste this prompt into the chatbox and press Enter to build the Services View:

Add the Services View (accessible from the Sidebar). It should show:
1. Service Cards in a grid layout, each showing: service name, status indicator (green=healthy, yellow=degraded, red=down), count of active incidents, last incident timestamp
2. Clicking a service card shows its recent incidents filtered from the Incidents table
3. A way to manually set a service's status (healthy/degraded/down)
Do not change the Dashboard or Incidents View.

What does this prompt do?

This prompt creates the final major view in your app. The color-coded status indicators (green, yellow, red) give instant visual feedback about system health. The click-to-filter interaction connects the Services View to the Incidents View you already built.

The manual status setter lets ops teams override a service's health when they know something the automated checks might not. This is a common pattern in real incident management tools.

Wait for Bolt to finish building.
Click Services in the sidebar navigation.
You should see a grid of Service Cards, each with a name, colored status dot, incident count, and timestamp.
Click one of the service cards. It should show that service's recent incidents.
Test the manual status setter by changing a service from "healthy" to "degraded" and confirming the status indicator turns yellow.

Services View not appearing in the sidebar?

If the sidebar still only shows Dashboard and Incidents, Bolt may not have added the route. Tell Bolt: "The Services link in the sidebar does not navigate to the Services View. Add routing for the Services page."

If service cards appear but clicking them does nothing, follow up with: "Clicking a service card should filter the Incidents table to show only incidents for that service."

Help me fix my Services View in Bolt.new that isn't routing or displaying correctly.

Polish and deploy your app

Your app is feature-complete. Before deploying, this is your chance to fix any visual inconsistencies. One common issue is severity badge colors not matching your intended design.

Review your app by clicking through each view (Dashboard, Incidents, Services).
If anything looks off, use a targeted prompt to fix it. For example, paste this to correct severity badge colors:

Make the severity badges use red for critical, orange for high, yellow for medium, blue for low

Keep polish prompts short and specific

Small, focused prompts use fewer tokens than broad "make everything look better" requests. Target one specific element per prompt (badge colors, font sizes, spacing) rather than asking for a general overhaul.

Once you are satisfied with how everything looks, click Publish in the top-right corner of your screen.
In the Publish your project menu that appears, click Publish again.
Wait about a minute for Bolt to deploy your site.
Click the link that appears in the chat window to open your live site in a new browser tab.

Why use the Publish button instead of prompting?

Clicking the Publish button does not use any of your tokens. Prompting Bolt to publish your site would decrease your token balance for no reason. Always use built-in buttons when they are available.

Your app deploys to a free .bolt.host domain that anyone can visit. You can share this URL with friends, add it to your portfolio, or include it in a job application.

You should now see your Incident Command Center live on the internet at its own URL. Try opening it in a different browser or on your phone to confirm it works for anyone.

Publish button not working?

If you see an error when publishing, make sure your project does not have any active build errors in the preview. Fix any errors Bolt reports in the chat, then try publishing again.

If the link does not appear in the chat window after a minute, refresh the page and click Publish again. The second attempt usually succeeds.

Help me deploy my Bolt.new project when the Publish button gives an error.

Secret mission

Post-Mortem Report Generator

Real incident management doesn't end when you click Resolved. Engineering teams write post-mortem reports to learn from outages and prevent them from happening again. Can you add this feature using the architecture-first approach you just learned?

Clean Up Your Resources

This project runs entirely in the browser on Bolt.new's free tier, so there are no ongoing costs. Decide whether to keep your project live, pause it for later, or delete it entirely.

Resources you used:

Bolt.new project (includes your database, code, and live deployment).
Architecture spec document (your plain-English data model, component tree, and state machine).
Bolt.new account (shared with StackBlitz).

Keep everything running

No action needed. Choose this if you want to keep your Incident Command Center live and accessible at its public URL.

Your app stays deployed and accessible to anyone with the link.
Your database and all incident data remain intact.
Your tokens reset on the 1st of each calendar month, so the project costs nothing to maintain.
The free tier includes a "Made in Bolt" badge on your deployed site.

Pause - I'll come back to this later

Your project stays saved in Bolt.new even if you close the browser tab. There is nothing to pause because there are no running processes or paid resources.

Close the browser tab. Your project is automatically saved.
To return later, go to https://bolt.new, click Projects, and open your Incident Command Center project.
Your live URL remains active while your account exists.

Delete - I don't want to use this again

Remove your Bolt.new project and optionally your account. This is permanent and cannot be undone.

Delete your Bolt.new project:

On the Bolt homepage, click Projects.
On the projects dashboard, click the three dots menu under your Incident Command Center project.
Click Delete, then click Delete again to confirm.
Log in to your StackBlitz account at stackblitz.com.
Click Collections.
Click the Bolt collection.
Click the menu icon for your project, then click Delete project.

Why two steps?

Bolt.new runs on StackBlitz under the hood. Deleting the Bolt project chat removes it from your Bolt dashboard. Deleting the StackBlitz project removes the underlying code and deployment.

Delete your architecture spec document:

If you saved your architecture spec locally, delete the file from your computer.
If you wrote it inside Bolt's Project Knowledge, it was deleted along with the project above.

Delete your Bolt.new account (optional):

Go to stackblitz.com/sign_in and log in.
In the left menu, click Settings.
Click the Profile tab.
Scroll down to the Account deletion section at the bottom of the page.
Click Delete my account.
Click Permanently delete my account to confirm.

This action is irreversible

Deleting your account removes all projects and data permanently. Only proceed if you are certain you no longer need access.

Nice Work!

You just built and deployed a production-style Incident Command Center. The kind of internal tool used by engineering teams at companies like Google, Amazon, and Netflix to manage live outages.

You've learned how to:

Build a full-stack Incident Command Center with a database, state machine logic, real-time dashboard metrics, and search/filter functionality.
Apply the architecture-first workflow: design your data model, component tree, and state machine BEFORE prompting the AI to build anything.
Deploy a live web app to the internet using Bolt.new's built-in hosting, shareable with anyone via a public URL.
Secret Mission: Added a post-mortem report generator using the architecture-first approach independently.

Ready to quiz yourself?