How to stop Supabase pausing your website: the wake-up call we built so it never does

Supabase pauses free projects after a week of low activity and Upstash archives them after fourteen days. It happened to us with Polish, our language coach. Here is the wake-up call we built to stop it, at no cost.

If your website relies on a database on a free plan, it can stop working without anyone laying a finger on it. Supabase pauses Free-plan projects when the database sees too little activity over a week, and Upstash archives its free Redis databases after fourteen days without use. The site still loads, but sign-in, data and anything that depends on the database stop responding. It happened to us on 4 November 2026 with Polish, our language coach, and we fixed it with a wake-up call: a script that touches every database twice a day and shouts if anything fails to answer. Here is what actually happens, how we built it, and what is worth checking on your own site.

The symptom is misleading. Polish is hosted on Vercel and the page loaded perfectly: design, copy, buttons. But signing in with Google did nothing, and in the browser console the database domain would not even resolve. Supabase had paused the project for inactivity, exactly as its documentation says it will: too little use over the past week and the project goes to sleep. They email you a week before and again when it happens, but those emails go to the account that owns the project, which is not always the inbox you check every day. Resuming it from the dashboard took about four minutes and nothing was lost: Supabase keeps the data and the configuration, and a paused project can be restored for up to a year.

This is not a bug and it is not a trick: it is the deal on the free plan. Supabase gives you two free projects per account and, in return, switches off the ones nobody uses rather than burn servers on empty databases. Upstash does much the same with Redis: according to its FAQ, after a minimum of fourteen days without activity it archives the database (it keeps a backup and removes the instance), and to get it back you create a new database and load that backup from the console. For a product with daily users this never happens. It happens to the things that live at the edges: a demo you showed a client three weeks ago, an internal tool that gets used in bursts, a prototype you will pick up "next month". Exactly the sort of thing an agency accumulates without noticing.

We had five databases in that position: Polish, Temprofit and a stock-count app for a café client on Supabase, plus two Upstash Redis stores holding visit counters and membership cards. Paying for a plan on each one made no sense for projects that earn little or nothing. So we built a wake-up call: a hundred-line bash script that runs on GitHub Actions twice a day, sends one minimal query to each database and, while it is at it, checks that thirteen of our sites and services respond. If everything is fine, the run goes green in under half a minute. If anything fails, it goes red and GitHub sends an email. It costs nothing: the free GitHub Actions minutes are more than enough.

  1. Pick queries that change nothing Every touch is a harmless read: asking for a profile with the public key (with no session, the database returns an empty list) or reading the visit counter for a site that does not exist. Nothing writes, nothing touches anyone's data. For it to count as activity, the database only has to receive the query.
  2. Use public keys only The script carries the same public (anon) keys that already ship in each site's code, stored as repository secrets. Two of our databases refuse to expose any table to that key, as they should, so we gave each a one-line SQL function that returns nothing but the current time. It is the only door it opens, and it shows nothing.
  3. Retry before you shout A network blip at seven in the morning is not an outage. Each check tries up to three times, waiting 15 and then 30 seconds, before it counts as a failure. That way the alert email only arrives when something is genuinely wrong.
  4. Don't schedule it on the hour GitHub sometimes drops scheduled runs when it is busy, especially at the top of the hour. Ours runs at 07:23 and 18:47 Madrid time. The first wake-up call we built, with a single daily run, skipped one on its very first day: that is why it now runs twice a day rather than once, and why it helps that Supabase's warning gives you a week's notice.
  5. Let the red do the talking What matters is not the daily green tick, it is the email when something fails. We added tresojotas.com itself, the service that renders Temprofit's invoice PDFs and the client sites we maintain to the list: eighteen checks in all. If a database gets paused anyway, we find out the same day, not when a user writes in.

If someone built your site months ago and it "just runs", three questions are worth asking. Where is the database, and on which plan? Which inbox receives that provider's warnings, and does anyone read it? What happens if the database goes off: does the site show a clear error, or does it look fine while nothing works, as ours did? A site that loads but won't let anyone in is worse than a clean outage, because nobody raises the alarm. And if the answer to the first question is "no idea", that is where to start.

In short: a free plan is a deal, not a gift, and the deal includes switching off whatever you don't use. A hundred-line wake-up call keeps your side of it: one harmless read twice a day, with public keys, retries and an email when something breaks. It has been running since 5 November 2026 for everything we keep on free plans (demos, prototypes and our own products), and it is the kind of thing we would rather sort out before a client discovers it for us. If you have a site or a prototype in that position and don't know what state it is in, tell us about it and we will take a look.