Common Bolt Issues

WebSocket connections fail to establish. Real-time features don't work. Users don't receive live updates.

Connection hangs or connects then disconnects immediately.

Long-running operations (file processing, email sending, bulk updates) timeout. Tasks don't complete.

Operations that take >30 seconds fail on serverless deployments.

POST or other non-simple requests fail because the CORS preflight OPTIONS request times out. Browser doesn't even send the actual request.

Requests work in some browsers but not others, or fail intermittently.

Users get errors when uploading files larger than limit. Upload fails even though file size seems reasonable.

Errors: 'payload too large', '413', or upload hangs indefinitely.

Emails aren't being sent. Email API returns success but users never receive the emails. Emails sent but marked as spam.

No error logs showing what went wrong.

API returns 429 Too Many Requests errors. Your app is making requests too quickly and hitting the rate limit.

Works initially then fails after rapid user actions.

Payment processing fails even though credentials look correct. Users can't complete purchases. Stripe API returns errors.

Sometimes charge attempts fail silently or return cryptic error messages.

You've registered a webhook URL but never receive requests from the service (Stripe, GitHub, etc.). The webhook endpoint is never called.

The service shows 'failed delivery' or 'pending' status.

API requests timeout while waiting for response. Frontend gets 'fetch timeout' error or 504 error.

The endpoint works but is slow. Same endpoint sometimes works, sometimes doesn't.

API requests fail with CORS error: 'Access-Control-Allow-Origin header missing'. The browser blocks requests to a different domain.

Your frontend is on one domain and API on another, or localhost vs deployed URL.

Your API route returns a 500 Internal Server Error even though the code looks correct. The same logic works fine when tested manually.

Frontend gets error when calling the route, but no detailed error message.

GraphQL queries with deep nesting cause timeouts or excessive server load. User can request deeply nested data causing exponential database queries.

Server becomes unresponsive to legitimate queries.

Application gets stuck in redirect loop. User is continuously redirected between login and dashboard, browser shows error about too many redirects.

Page loads then immediately redirects, causing infinite loop.

Users log in successfully but get logged out whenever they refresh the page or return later. The session persists during the same browser tab but is lost on navigation or reload.

This happens because authentication state isn't being saved to browser storage or the session storage isn't being retrieved on app initialization.

Your protected routes are either accessible without authentication or they continuously redirect authenticated users to login. Protected pages don't check auth status before rendering.

Users see blank pages, infinite redirect loops, or pages load with unauthenticated state briefly before hiding content.

API requests fail with JWT verification errors even though the token appears valid. Tokens work initially but fail after some time or across different server instances.

Symptoms include immediate '401 Unauthorized' on API calls, 'JsonWebTokenError: invalid signature', or tokens expiring immediately after issue.

Your OAuth2 provider (Google, GitHub, Facebook) authentication fails immediately with cryptic errors. The login redirect works but authorization fails.

Common signs: blank page on OAuth callback, 'client_id not found' in browser console, or authentication loops indefinitely.

You've burned through your Bolt.new tokens and your app still has issues. Bolt uses a token-based system where every AI interaction consumes tokens, and complex tasks can eat through them surprisingly fast.

Maybe you're stuck on a deployment issue, a broken API integration, or a UI bug that the AI keeps making worse with each attempt. Each failed attempt costs tokens, and you're watching your balance drop without the problem getting solved.

Before you reach for your credit card to buy more tokens, consider whether more AI attempts will actually solve the problem — or whether a different approach would be faster and cheaper.

Users see old data from Redis cache even after updates. Cache doesn't invalidate when data changes.

Data appears correct in database but cached version is stale.

Firebase authentication never initializes. Login and signup endpoints return errors. The Firebase console shows requests aren't being received.

Common signs: 'Firebase app not initialized', 'auth/invalid-api-key', or auth always returns null.

Requests to Supabase hang indefinitely or timeout after 30 seconds. Login, signup, or database queries never complete.

The app connects fine locally but fails on deployment, or works initially then starts timing out under load.

Database connections accumulate over time. Pool reaches max connections and new queries fail. Eventually app becomes completely unresponsive.

Connection count grows with each request and never decreases.

Database queries timeout or take too long (>5 seconds). Complex queries with joins or aggregations are slow.

API endpoints that query database time out or users see loading spinners for too long.

Running `prisma migrate dev` fails with schema validation errors. The app can't sync with the database schema or migrations won't apply.

You see errors about 'Migration already applied', schema divergence, or the database being in a bad state preventing any migrations.

API requests start failing with 'too many connections' or 'connect ECONNREFUSED' errors. The database was working fine but suddenly stops accepting connections.

This typically happens under load or after the app has been running for a while, and restarting the app temporarily fixes it.

Netlify build fails due to plugin configuration errors. The deploy log shows 'Plugin error' but the app builds fine locally.

Specific plugin (Node version manager, environment variable handler, etc.) fails during the build process.

npm install fails or warns about version conflicts. Packages require different versions of the same dependency.

Error: 'peer dep missing' or 'conflicting peer deps'

API routes that work fine locally timeout on Vercel. Long-running tasks like file processing, bulk database operations, or external API calls exceed the timeout limit.

Requests return 504 Gateway Timeout and logs show the function was killed.

Deployment build fails with 'killed' status or 'out of memory' error. The build process gets terminated by the system before completing.

This happens when building large applications with many dependencies or heavy bundling requirements.

Environment variables are undefined in your deployed application even though they're set in the platform. API keys, database URLs, and other config values come back as undefined.

Variables work fine locally but disappear after deployment.

Your app works perfectly in development but shows a blank white page after deploying to Vercel or Netlify. No errors in the browser console, just whitespace.

The deployment log shows 'Build succeeded' but the page won't render anything.

Your build fails because of ESLint warnings/errors. Code is correct but linter complains and build exits.

Works locally with warnings but deployment fails on lint.

TypeScript reports type errors that prevent build. Type checking fails even though code appears correct.

Build exits with 'TypeScript error found' message.

Your Bolt.new application has a contact form that appears to work perfectly: users fill it out, click submit, and see a 'Thank you, message sent!' confirmation. But the email never arrives. You only discover the problem when someone follows up asking why you never replied to their inquiry.

This is a devastating issue for business websites. Every missed contact form submission is a potential lost customer, partnership, or support request. The false success message makes it worse because the sender believes their message was received and doesn't try to contact you through other channels.

Bolt's AI often generates beautiful contact form UIs with client-side validation but doesn't properly implement the backend email sending logic. The form submits to an API route that either doesn't exist, doesn't actually send the email, or silently fails without error handling.

Users click 'Forgot Password' in your Bolt.new application and see a success message, but the password reset email never arrives in their inbox. They check their spam folder, wait hours, and still nothing. This locks users out of their accounts with no way to recover access.

Password reset is a critical authentication flow, and when it's broken, users have no self-service path to regain access. They'll either abandon your app entirely or flood your support channels. The problem is especially frustrating because the UI shows a success message even when email delivery fails.

This commonly happens because Bolt sets up authentication with Supabase Auth but doesn't configure email delivery beyond Supabase's built-in email service, which has strict rate limits and often lands in spam. For production apps, you need a proper email delivery service.

Users receive notification emails from your Bolt.new application (order confirmations, status updates, invitation links), but when they click the links, they land on 404 pages, localhost URLs, or completely wrong pages. The emails are being delivered but every link inside them is broken.

This destroys user trust immediately. A customer who receives an order confirmation with a broken tracking link, or a team member who gets an invitation email that leads to a 404, will question whether your entire application is legitimate. Broken email links are one of the most visible and damaging bugs.

The root cause is almost always that the URLs in email templates are hardcoded to your development environment or constructed incorrectly. Email templates are generated once and don't automatically update when your app URL changes from development to production.

Your Bolt.new application's PayPal integration fails at various stages: the PayPal button doesn't render, orders fail to create, or payments are captured but never confirmed. Users see 'Something went wrong' messages, empty payment popups, or get charged without the order being recorded in your system.

PayPal integration involves multiple steps - loading the SDK, creating orders, capturing payments, and handling webhooks - and Bolt's AI-generated code often gets one or more steps wrong. The PayPal popup may flash and close immediately, or payments may succeed on PayPal's side but fail to record in your database.

This is particularly dangerous when payments are captured by PayPal but your app doesn't record the transaction, leaving you with money collected and no order created. The customer paid but got nothing, requiring manual refunds and damaging trust.

Your Bolt.new application is set up with Firebase Cloud Messaging (FCM) for push notifications, but users never receive them. The notification permission prompt may not appear, tokens fail to generate, or notifications are sent from the backend but never arrive on users' devices.

Push notifications are essential for user re-engagement: notifying users about new messages, order updates, price alerts, or time-sensitive events. When they don't work, your app loses its ability to bring users back, and you have to rely entirely on email which has much lower engagement rates.

Firebase push notifications involve multiple moving parts: a service worker on the client, a valid FCM token per device, proper Firebase configuration, and a server-side component that sends the actual notifications. Bolt's AI typically sets up some of these pieces but misses critical configuration steps.

Users trying to log in with Google in your Bolt.new application encounter errors like 'This app isn't verified', 'Error 400: redirect_uri_mismatch', or a consent screen that requests terrifying permissions like 'See, edit, download, and permanently delete all your Google Drive files'. Some users see a blank screen after clicking 'Sign in with Google'.

Google OAuth is the most common social login provider, and a misconfigured consent screen will stop every user from signing up or logging in. The scary permission warnings or 'unverified app' screens cause users to immediately close the tab and never return, even if your app only needs basic profile information.

The issue stems from Google Cloud Console configuration not matching what your application code expects. Bolt generates the OAuth login flow in code but can't configure the Google Cloud Console for you, leading to mismatches between what Google expects and what your app sends.

Your Bolt.new application uses Twilio for SMS notifications (verification codes, order updates, appointment reminders) but messages are never delivered. The API calls appear to succeed, or they fail with cryptic error codes, and users never receive the SMS on their phones.

SMS is often used for critical user flows like two-factor authentication and order notifications. When it fails, users can't verify their phone numbers, miss important updates, or can't complete checkout processes that require SMS verification. Unlike email, there's no spam folder to check - the message either arrives or it doesn't.

Twilio has strict compliance requirements, number formatting rules, and sender registration requirements that Bolt's AI-generated code often doesn't account for. A message that works when testing with your own phone may fail when sending to other numbers, carriers, or countries.

When users tap on input fields, text areas, or select dropdowns in your Bolt.new app on an iPhone or iPad, Safari automatically zooms into the field. The page stays zoomed in after the user finishes typing, forcing them to manually pinch-to-zoom out before they can continue using the app.

This is one of the most frustrating mobile UX issues because it happens on every single form interaction. Login forms, search bars, checkout fields, and contact forms all trigger the zoom. Users have to zoom out after every input, making forms feel broken and unprofessional.

The behavior is specific to iOS Safari and happens because Apple's browser auto-zooms on any input field with a font-size smaller than 16px. This is a deliberate accessibility feature to help users read small text, but it becomes a problem when your design uses 14px or 12px font sizes for inputs.

The fixed bottom navigation bar in your Bolt.new app covers the last items on every page. Users cannot see or tap buttons, form submit actions, and the last few items in lists are permanently hidden behind the nav bar. Scrolling to the bottom doesn't help because the nav bar moves with the viewport.

This is especially problematic on pages with action buttons at the bottom (checkout, submit, save), infinite scroll lists, and chat interfaces where the input field is at the bottom. Users literally cannot complete key actions because the navigation bar is covering them.

The problem gets worse on iPhones with the home indicator bar (iPhone X and later), where the safe area inset adds additional space that pushes the nav bar higher but doesn't account for the content behind it.

The hamburger menu icon in your Bolt.new application is visible on mobile screens but nothing happens when users tap it. Alternatively, the menu opens once but then refuses to close, or it opens behind other page content and is invisible.

Mobile navigation is critical for user experience, and a broken hamburger menu effectively makes your entire app unusable on phones and tablets. Users cannot access any page other than the one they landed on, causing immediate bounce rates and lost conversions.

This issue is extremely common in Bolt-generated apps because the AI creates the toggle logic and CSS transitions but doesn't always handle the interaction between state management, z-index stacking, and touch events correctly on real mobile devices.

Your Bolt app takes minutes to build even with small changes. Development speed suffers with slow hot reload and rebuild times.

npm run dev or npm run build takes excessive time (over 30 seconds for simple changes).

Your Bolt WebContainer takes a long time to start - 30+ seconds before seeing the dev server running. Development workflow is slow due to startup delays.

This happens consistently, making every new session wait.

Fonts load slowly causing text to flash or shift layout (Cumulative Layout Shift). Users see unstyled text briefly before custom font loads.

This impacts Core Web Vitals and user experience.

Your app gradually uses more memory the longer it runs. DevTools shows increasing memory usage even after navigating away from components.

The app slows down over time or crashes after extended use.

Your JavaScript bundle is very large (over 500KB), making the app slow to load. First Contentful Paint takes several seconds even on good connections.

Users on slow networks experience long loading times.

Your app feels sluggish when interacting. Typing in inputs lags, clicking buttons is unresponsive. React is re-rendering too much.

Frame rate drops during interactions or when state updates happen.

Your Bolt.new application has a notification system that stores notifications in the database, but users only see them after refreshing the page. The notification bell or badge doesn't update in real-time, so users miss time-sensitive alerts like new orders, messages, or system warnings.

Live notifications are essential for any interactive application. When a user receives a new message, a buyer places an order, or a system event requires attention, the user needs to know immediately without manually checking. A notification system that requires page refreshes defeats its entire purpose.

Bolt typically generates the notification storage and display components but misses the real-time delivery mechanism. The notifications exist in the database but the frontend has no way to know about new ones until it re-fetches the list.

Your Bolt.new application has a collaborative editing feature (shared documents, kanban boards, whiteboards) where multiple users should be able to edit simultaneously, but changes from one user overwrite another's work, edits don't appear in real-time, or the document gets into a corrupted state with missing or duplicated content.

Collaborative editing is one of the hardest technical challenges in web development. It requires real-time synchronization, conflict resolution, presence awareness, and careful state management. When Bolt generates collaborative features, it often implements basic database saving without the synchronization layer that makes true collaboration work.

Users experience this as: changes disappearing after they save, seeing stale content that doesn't match what others are editing, or two users making simultaneous changes where only the last save survives and the other's work is lost.

Your Bolt.new chat feature saves messages to the database correctly, but other participants don't see new messages until they manually refresh the page. The chat feels like an email inbox rather than a live conversation, making real-time communication impossible.

Users expect chat to be instant - messages should appear within milliseconds of being sent. When they have to refresh the page to see responses, they assume the feature is broken and will abandon it for a working alternative. This is a fundamental functionality issue that undermines the entire purpose of a chat feature.

The root cause is that Bolt generated a working CRUD interface for messages (create, read, update, delete) but didn't implement the real-time subscription layer that pushes new messages to connected clients as they arrive.

Your Bolt.new application accepts user input from forms, URL parameters, and API requests without validating or sanitizing it. This leaves your app vulnerable to cross-site scripting (XSS), HTML injection, data corruption, and other attacks that exploit unfiltered input.

When Bolt generates form handling code, it often passes user input directly to the database or renders it on the page without checking for malicious content. A user could submit a script tag in a comment field, an extremely long string that breaks your layout, or special characters that corrupt your data.

The consequences range from cosmetic issues (broken layouts) to critical security breaches (stolen user sessions, defaced pages, or unauthorized data access). This is one of the most common security gaps in AI-generated applications.

Your Bolt.new application is bundling sensitive environment variables into the client-side JavaScript code. Anyone who opens browser DevTools can see your API keys, database connection strings, Stripe secret keys, or other credentials that should never leave the server.

This happens because Bolt's AI may prefix environment variables with VITE_ or NEXT_PUBLIC_, which tells the bundler to include them in the frontend build. While this is correct for public configuration like your site URL, it exposes any secret placed behind those prefixes.

The exposure is often discovered when you receive a massive bill from a third-party API, notice unauthorized data in your database, or when a user reports finding credentials in your page source. By then, the damage may already be done.

Your Bolt.new application contains SQL injection vulnerabilities in its database queries. The AI-generated code concatenates user input directly into SQL strings instead of using parameterized queries, allowing attackers to manipulate your database.

An attacker can exploit this by entering specially crafted input into form fields, search boxes, or URL parameters. For example, entering ' OR 1=1 -- into a login form could bypass authentication entirely, or entering '; DROP TABLE users; -- could delete your entire users table.

This vulnerability is particularly dangerous because it can go completely unnoticed during normal use. The app works perfectly with legitimate input, but an attacker with basic SQL knowledge can read, modify, or delete any data in your database.

Your Bolt.new application stores authentication tokens or session data in cookies without proper security attributes. Missing HttpOnly, Secure, and SameSite flags leave your users' sessions vulnerable to theft through XSS attacks, man-in-the-middle interception, and cross-site request forgery.

When Bolt generates authentication code, it may set cookies using basic document.cookie assignments or use a cookie library with default (insecure) settings. This means session tokens can be read by JavaScript (enabling XSS-based theft), transmitted over unencrypted HTTP connections, and sent along with cross-site requests.

An attacker who steals a session cookie can impersonate any user on your platform, access their data, make purchases on their behalf, or escalate privileges to admin accounts. This is a silent vulnerability that leaves no trace until it's exploited.

Your Bolt.new application loads images at full resolution regardless of display size, causing slow page loads, excessive bandwidth usage, and poor Core Web Vitals scores. A 5MB profile photo is served at 4000x3000 pixels even though it's displayed at 100x100 on the page.

Bolt's AI typically generates basic img tags or stores images exactly as uploaded without any processing. This means a user uploading a 10MB DSLR photo gets that exact 10MB file served to every visitor, even on slow mobile connections.

The problem compounds quickly: a page with 20 user-uploaded images can require 50MB+ of downloads, making your app unusable on mobile and destroying your Google PageSpeed score. Image optimization is one of the biggest performance wins for any web application.

Your Bolt.new application fails to upload, read, or delete files from cloud storage. Users get permission denied errors when trying to upload profile pictures, access shared documents, or view images that should be publicly visible.

Cloud storage services like Supabase Storage and AWS S3 use policy-based access control. If these policies are too restrictive, legitimate operations fail. If they're too permissive, anyone on the internet can read or modify your files. Bolt's AI often generates storage code without configuring the bucket policies correctly.

This typically surfaces right after connecting cloud storage: uploads fail with RLS policy violations, images return 403 errors, or users can see other users' private files because the policies are set to public.

File uploads in your Bolt.new application work perfectly during development in the WebContainer but fail completely after deploying to production. Users see upload spinners that never finish, error messages about failed requests, or files that appear to upload but are never saved.

This is one of the most common deployment issues with Bolt apps because the WebContainer environment handles file storage differently than production hosting. Files stored locally during development have no persistent storage on serverless platforms like Vercel or Netlify.

The issue can manifest in several ways: uploads timeout with 413 or 504 errors, files are saved but disappear after deployment redeploys, or the upload endpoint returns CORS errors that didn't exist in development.

Modal dialogs aren't accessible. Users can tab to elements behind the modal, keyboard focus isn't trapped, or screen readers don't announce the modal.

Accessibility testing tools flag issues with focus management and ARIA attributes.

Using next/image causes errors. Image won't load or throws configuration error. Image optimization fails.

Error about missing width/height, or optimization service unavailable.

Users fill out a form and click submit, but nothing happens. The form doesn't send data to the backend. No errors displayed.

Sometimes the page refreshes but data isn't saved.

Images aren't showing on the page. You see the broken image icon or blank space where images should be.

The image tag exists in HTML but the source isn't loading.

You add onClick, onChange, or other event handlers to elements but they never fire. The function is defined but not being called when the event occurs.

Sometimes works in one component but not another. No console errors.

You update React state with setState() or useState hook, but the component doesn't re-render. The state seems to update in DevTools but the UI doesn't change.

This happens with objects and arrays particularly.