When Your Platform Switches Your App Off: A Survival Plan for AI-Built Businesses

If your hosting or app platform suspends your project, your business survives only if three things already exist before that morning: a recent copy of your data in storage you own outside the platform, a restore you have actually tested, and a way to tell customers what is going on that does not depend on the app being up. The platform is almost never the villain in this story. Every major one (Vercel, Netlify, Supabase, Firebase, Lovable, Replit) publishes terms that let it pause or suspend a project that overloads its systems or someone else's, and those terms protect every other customer on the same infrastructure, you included. You cannot control whether a suspension happens. You can control whether it costs you an afternoon or the company.

The short version

• Suspension is a normal, documented power. Every platform you are likely to build on reserves it in writing, and it can apply to a project run by people with good intentions.
• The usual trigger is your own code doing something you did not plan. A loop that never stops, an endpoint strangers found, a key that leaked, a quota that ran out.
• A backup on the same platform is not a plan. If the account is locked, every copy inside it is locked too.
• Seven steps, mostly settings and a few hours of work, turn a suspension from a crisis into an inconvenience.
• The first 24 hours follow a script. Find out exactly why, fix the cause, write to support once and well, tell customers early, and restore elsewhere if the wait gets long.

What does a platform suspension actually look like?

Picture a business built with AI tools. Maybe it started in an app builder, maybe someone moved it to a proper hosting setup later. It has been running for months. Real customers, real orders, a database that is now the most valuable thing the founder owns.

One morning the site shows an error page instead of the product. The dashboard shows a banner that the project has been paused or suspended. There is an email, often brief, saying the account was flagged. Overnight, a server function sent an unusual flood of requests to an outside service, maybe a payment API, an email provider or an AI model, and the platform's automated systems did what they are built to do: they stopped it.

Production is down. The admin panel lives on the same platform, so that is down too. The database sits behind the same account, so exporting it is not possible either, at least not until support reviews the case. And support reviews take time. Days, sometimes.

This is a pattern, not a story about any one company. Versions of it show up across very different stacks, and the shape is always the same: the app was fine, the code had one weak spot, the platform reacted the way its terms say it will, and the founder discovered at the worst possible moment that every copy of the business lived in one place.

Nobody can promise it never happens to you. The real question is whether your business keeps breathing while it does.

Why do platforms suspend apps that did nothing wrong on purpose?

Because the platform cannot see your intentions, only your traffic. And shared infrastructure only works if one customer's runaway project cannot take down everyone else's.

Here is what the official documents say, in each platform's own words:

• Vercel publishes fair use guidelines and says that misusing its limits or usage guidelines is "a violation of our fair use guidelines." Its own help article on why an account or deployment gets paused lists spend settings, usage limits, policy violations and platform incidents as the causes, and says visitors to a paused production site see a 503 DEPLOYMENT_PAUSED error.
• Netlify's acceptable use policy says users must not "create an undue burden on the website or the networks or services connected to the website." Separately, on its credit-based plans, Netlify documents that once the credit balance is used up, all web projects are paused and visitors see a "Site not available" page.
• Supabase's acceptable use policy prohibits "inundating a target with requests" and says a violation "may result in the immediate suspension or termination" of accounts or services. Its cost control page adds that services will be restricted under its fair use policy if a project consistently exceeds its quota.
• Firebase projects are, in Google's own words, "just a Google Cloud project" with extra services enabled. Google Cloud's suspension guidelines say that when a project is suspended, "existing workloads are shut down, and users lose access to the suspended Project resource."
• Lovable's terms say it may suspend an account "immediately, without prior notice" if it reasonably believes the terms were materially breached, and they ask users not to "overload, disrupt, or interfere with the normal operation of the Services."
• Replit's usage limits page lists, among others, a limit on concurrent outgoing network connections, and says that if limits are exceeded, an app "may become temporarily unavailable."

Read with a calm head, these are reasonable. A platform that let one project flood an email service would soon lose that service for every customer. The uncomfortable part is simple: the protection does not ask whether you meant it.

What usually causes the flood?

In AI-built apps, four causes come up again and again. None of them requires bad intent, and most of them are invisible in a demo.

1. A runaway loop. A retry that retries forever. A webhook that triggers an update, which triggers the same webhook. A scheduled job that processes the same rows every minute because it never marks them done. The AI tool wrote code that works on the happy path; nobody asked what happens when the outside service answers slowly or returns an error.
2. An open endpoint that strangers found. A function that sends an email, charges a card, calls an AI model or sends a text message, with no login and no limit. Bots scan the internet for exactly these. Once they find one, your function starts working for them, and the platform sees your project attacking someone.
3. A leaked key. An API key pasted into front-end code, committed to a public repository or visible in the browser's network tab. Someone else now spends your quota, from your account, under your name.
4. A quota overrun. No attack at all. A launch goes well, a post goes viral, traffic spikes past what the plan allows, and the platform pauses the project under its usage rules.

The OWASP API Security Top 10 names this whole family "unrestricted resource consumption" and recommends two plain defenses: rate limiting, and spending limits on every outside provider, or billing alerts where limits are not possible. That advice is the backbone of the steps below.

Seven steps to take today

None of these needs a rewrite. Most are settings, a scheduled job and a few documents.

1. Back up nightly to storage you own, outside the platform

This is the step that decides everything else. A backup inside the suspended account is a backup you cannot reach. The copy has to live under a different provider, a different login and a different payment method.

For a Postgres database, that means a scheduled dump (Supabase, for example, recommends its CLI db dump command for logical backups and says projects on its entry tier should "maintain off-site backups") written to a storage bucket at another provider. Include the uploaded files too: product photos, contracts, attachments. A database without its files is a store without pictures.

Ask one question of the destination: if someone took over my hosting account tonight, could they delete these copies? If the answer is yes, it is not separate yet. The longer version of this argument, with the 3-2-1 rule and restore objectives, is in our backups and disaster recovery guide.

2. Test a real restore

A backup you have never restored is a hope. Once, this month, take last night's copy and bring it up somewhere that is not production: a new database at a different provider, a local machine, a staging project. Open the app against it. Log in as a test customer. Check that the latest orders are there and that the images load.

Write down how long it took and every step you had to figure out. That note becomes your runbook. We cover the restore drill in more depth in automate your backups before you lose data.

3. Put rate limits and authentication on every function

Go through every server function and ask two questions: who is allowed to call this, and how often? A function that sends email should require a logged-in user or a verified form token, and should refuse the hundredth request from the same address in a minute. A function that calls a paid API should have a hard ceiling per user and per hour. A webhook receiver should check the signature before doing anything.

Most hosting platforms offer a firewall or rate limiting layer you can turn on without code, and most databases let you lock tables so only the right user can read them. If your app came out of an AI builder, assume none of this was set up unless you asked for it by name. Our guide to launching an AI-built app safely walks through the full list.

4. Turn on usage and billing alerts everywhere

Every provider your app touches should be able to wake you up before it bills you or cuts you off. On Vercel, spend management sends notifications at 50%, 75% and 100% of the amount you set, can call a webhook, and can pause production deployments when the amount is reached. That last option is worth a thought: a deliberate pause you chose is far easier to undo than a suspension you did not.

Do the same at the AI provider, the email service, the SMS provider and the payment processor. Set the alert low enough that a normal busy day does not trigger it and an abnormal night does.

5. Keep keys on the server only

Any key that can spend money or read customer data belongs in server-side environment variables, never in the front-end bundle and never in the repository. Search your code for strings that look like keys. Open your live site, open the browser's developer tools and look at the network requests: if you can see a secret there, so can everyone else.

If a key has ever been exposed, rotate it now, not after you finish reading. Rotating takes minutes; a stranger spending your quota takes your project offline.

6. Watch from the outside, and recognize a suspension page

Your platform's dashboard cannot tell you the platform turned you off; it is the thing that is off. You need a monitor that sits somewhere else and checks the public address every few minutes, the way a customer would.

Make sure it knows the difference between "down" and "suspended." A paused or suspended project often answers with a tidy error page and a status code that some simple monitors treat as fine. A good check looks for the words and codes the platforms actually use (for example Vercel's DEPLOYMENT_PAUSED or Netlify's "Site not available" page) and tells you which one it saw. Knowing in the first five minutes that this is a suspension, not a crash, changes who you call first. Our guide to observability for small apps covers what else is worth watching.

7. Prepare a status page and a customer message

Set up a simple status page on a different provider than your app, with its own address. Write the customer message now, while you are calm:

Subject: [Your product] is temporarily unavailable

Hi,

Since [time and time zone], [your product] has been unavailable.
Your data is safe: we keep independent backups outside our hosting provider.
We are working on it now and will update you by [time], and every
[few hours] after that, at [status page address].

If you need something urgent in the meantime, reply to this email
and a person will answer.

[Your name]

Keep the list of customer emails in that off-platform backup too. A message you cannot send because the mailing list lived inside the suspended app does not help anyone.

The first 24 hours after a suspension

The worst version of this day is the one where you improvise. Here is the order I would work in.

Hour 0 to 1: find out exactly what happened. Read the platform's email and the dashboard banner word for word. Is it a usage pause, a billing pause or a policy suspension? They have different exits. Check the logs you can still reach, the outside providers' dashboards and their usage graphs. You are looking for the one function or key that went wild.

Hour 1 to 3: stop the cause, even if the platform already did. Rotate the keys that could have been involved. Put a limit or a login on the function that ran away. Disable the scheduled job that looped. Make the fix in your repository, which should live outside the platform, so it is ready to deploy the moment you are allowed back. Support will ask what you changed, and "nothing yet" is the slowest possible answer.

Hour 1 to 3, in parallel: contact support once, clearly. One message, through the channel the suspension email names, with everything they need:

Account / team: [name and ID]
Project: [name and ID]
Suspended at: [time and time zone, from your notice]

What happened: Our function [name] sent an unusual volume of requests to
[outside service] between [time] and [time]. The cause was [a retry loop /
an unprotected endpoint / an exposed key].

What we have done: [rotated the key / added authentication and a rate limit
of N per minute / removed the job]. The fix is in commit [link or hash].

What we ask: reinstatement of the project, or if review will take longer,
temporary read-only access so we can export our data.

This is a production business with paying customers. We will answer any
question you have within the hour.

Be factual, take responsibility for your code, and do not argue the policy. The person reading it is deciding whether you are a careful operator who had a bad night. Help them see that.

Hour 2: tell your customers. Send the message from step 7 and post on the status page. People forgive an outage they hear about from you. They do not forgive one they discover from a broken checkout.

Hour 4 onward: decide whether to restore elsewhere. If support has not answered by a time you decide in advance, start bringing the business up from your backup on another provider. With a tested runbook this is a matter of hours: create the database, load the dump, deploy the same repository with the same environment variables, point the domain at the new address. Domain control matters here; if your domain's DNS is managed by the platform that suspended you, moving it may be the slowest step, which is a good reason to keep DNS with your registrar or a separate DNS provider.

Hour 24: write down what you learned, then close whichever of the seven steps you had skipped.

Managed database or your own: what is the trade-off?

This question always follows the scenario above, so here is my honest take.

A managed database from your app platform (the one bundled with your builder, or one connected through the platform's marketplace) is the fastest way to start. Backups, updates and scaling are handled for you, and for most early products it is the right choice. The trade-off is that your data and your app often share an account, a login and a billing relationship. When that relationship is paused, both stop together, and the platform's own backups are reachable only through the platform.

A database at a separate provider (a dedicated managed Postgres service, or a database you run yourself) puts a wall between the app and the data. If the app host suspends your project, the database keeps running and your data stays reachable. You can deploy the app elsewhere and point it at the same data. The cost is one more account, one more bill and a little more setup, plus the responsibility for watching it.

Running it fully yourself on your own server gives you the most control and the most chores. For most small businesses that is more risk than it removes.

My default advice for an AI-built business that now has real customers: keep a managed database, but at a provider separate from the app host, and keep the nightly copy at a third place. Three accounts, three logins, and no single morning can take everything. If you are earlier than that, stay where you are and do step 1 tonight; it gets you most of the protection for almost none of the effort. When it is time to move, our guide on escaping no-code lock-in and the piece on moving a Bolt.new project to Vercel show how the move usually goes.

Common pitfalls

These are the patterns that turn a recoverable suspension into a long week.

• The backup lives in the same account. The platform's automatic backups are real and useful, but when the account is locked, they are locked with it.
• The backup has never been restored. The dump runs every night and nobody has noticed it has been writing empty files since a password changed.
• Only the founder can log in. The hosting account, the database, the backup bucket and the domain are all tied to one email and one phone. That person is on a plane.
• The domain is managed by the app platform. The data is safe and the app is ready elsewhere, but pointing the domain at it means waiting on the same support queue.
• The customer list is inside the app. Everything is ready except the one thing you need first: a way to reach your customers.

A composite example, built from patterns rather than any one business: a small subscription app ran its signup welcome email through a server function with no login and no limit. Bots found the form and used it to send messages to addresses they chose, far more than the app had ever sent, through the app's email provider. The provider flagged it, the hosting platform paused the project, and the founder learned about it from customers. Every tool behaved exactly as documented. What was missing was a limit on one function and a copy of the data somewhere else.

How we approach this with clients

When I take on an AI-built app, this plan is part of the first phase, not an extra. The first phase has a fixed scope: we map where the code, data, domain and keys live, put the nightly off-platform backup in place, run the first restore together on a call so you see it work, and add limits and alerts to the functions that can spend money. You own the code, the data and every account; I work inside them, not instead of them. Each step ends with a short demo before we move to the next, and you talk to me directly the whole way.

If you want a second pair of eyes on how exposed your app is today, tell me what you run and I will give you a straight answer, including when the answer is that you only need a settings change and a calendar reminder.

A checklist you can copy

[ ] Nightly database backup to storage at a different provider
[ ] Uploaded files included in the backup
[ ] Backup storage under a different login and payment method
[ ] A real restore tested this month, with the time it took written down
[ ] A one-page restore runbook stored outside the platform
[ ] Every server function requires a login, a signature or a verified token
[ ] Every function that spends money has a rate limit and a ceiling
[ ] Spend or usage alerts on: hosting, database, AI, email, SMS, payments
[ ] No secret keys in front-end code or in the repository
[ ] Any key that was ever exposed has been rotated
[ ] Outside monitoring that recognizes a down AND a suspension page
[ ] Status page hosted on a different provider
[ ] Customer message drafted and customer email list backed up
[ ] Support message template with account and project IDs filled in
[ ] Code repository outside the hosting platform
[ ] Domain DNS managed outside the hosting platform
[ ] A second person who can log in to every critical account

FAQ

Can a hosting platform really suspend my app without warning?

Yes, and it is written into their terms. Lovable's terms, for example, allow suspension "immediately, without prior notice" for a material breach, and Supabase's acceptable use policy allows immediate suspension for violations. Vercel says that where possible it will reach out before acting on unreasonable usage, but a flood happening right now may not leave time for that. Plan as if there will be no warning.

Will I lose my data if my project is suspended?

Usually not permanently, but you may lose access to it for as long as the review takes. Google Cloud, for example, says users lose access to a suspended project, and marks a project for deletion only after it has been suspended for more than nine months. The real risk is the gap: days without your data is enough to hurt a business that has no copy of its own.

Should I move off my platform after a suspension?

Not by reflex. If the cause was your code, it would have caused the same reaction anywhere, because every platform has the same kind of policy. Fix the cause, restore service, and then decide calmly whether separating the database from the app host is worth it for you.

What should I say to support to get reinstated faster?

Give them the account and project IDs, the exact cause, what you already changed with a link to the commit, and a clear request. If review will take a while, ask for temporary read-only access to export your data. A short, factual, responsible message is easier to approve than a long one that argues.

One more thing

If you want to know the moment it happens, 7IT Guard watches your app from the outside, recognizes both an ordinary down and a platform suspension page, and tells you in plain words which one it is and what it means. You can read how it works on the 7IT Guard page.