Lucia

Once it works, remember that the registration lives on the provider's side and can drift.

If you rebuild the container, change the public URL, or restore from a backup, you can end up with the provider holding a registration pointing at something that no longer exists, and your fresh instance thinking it is fine. Deactivate and reactivate after any of those.

Worth putting an alert on it too — a workflow that quietly stops receiving is much worse than one that errors, because nothing tells you.

Unblocking suggestion for right now, separate from the diagnosis: you do not need the desktop app to keep working.

Most of these tools have a browser version that reaches the same synced workspace, and there are command-line and editor-based alternatives that read a plain text file of requests. If you are blocked on a deadline, spend ten minutes moving the two or three requests you need rather than an hour on the crash.

The longer-term version of that: keeping your requests as a file in the repository, next to the code they exercise, means they are versioned with the API, reviewable in a diff, and immune to any single tool's local database going bad. I moved for exactly this reason after the second time this happened.

Get the number before you make any decision, because the two outcomes here are wildly different and people usually guess wrong about which one they are in.

Getting the honest number.

1. Find the usage view, not the pricing page. Every one of these platforms exposes current consumption per resource — compute time, memory-hours, storage, egress, database size, request counts. That is your actual consumption in the platform's own units, which is the only thing that multiplies cleanly against their rates.
2. Multiply it out by hand, per line. Do not trust a summary estimate. Take each metered dimension, take your last full month of it, multiply by the published rate, and write the lines down. The exercise takes twenty minutes and it almost always produces one surprising line.
3. Set a spending limit or a budget alert immediately, whatever they offer, at a number you would be annoyed but not hurt by. Do this before the analysis, not after. It is the difference between learning you were wrong from a notification and learning it from an invoice.

The line that surprises people is usually one of these three:

• Idle compute. Under an always-free allowance, an app sitting there doing nothing was free. Under usage billing, a container that runs 24/7 bills for 24/7 whether anyone visits or not. For a low-traffic app this is normally the entire bill. If the platform supports scaling to zero and starting on request, turning that on can take the cost of a hobby app to near nothing. The trade is a cold start on the first request after idle, which for a side project is usually completely acceptable.
• The database. Managed databases are often the largest single line and frequently cannot scale to zero, because something has to hold the data. A small always-on database can cost more than everything else combined.
• Egress. Usually trivial for an API. Not trivial if you serve images or files. Check before assuming.

Then the stay-or-move decision, which is mostly about the shape of your app rather than the price.

• A stateless container moves in an afternoon. It is a Dockerfile and some environment variables, and half a dozen platforms will run it. If that is all you have, your switching cost is genuinely low and you can be relaxed about it.
• State is the expensive part. A managed database, a queue, object storage, scheduled jobs, anything with a platform-specific API — that is what makes migration a project rather than an evening. Count those honestly before deciding you can leave whenever you like.

My actual advice, having done this twice: if the number comes out to less than a couple of coffees a month, pay it and get on with your life. The hours you would spend migrating are worth more, and a paid account tends to be a more stable place for something you care about than a free tier that exists at somebody's discretion.

If the number is genuinely uncomfortable, fix the shape first — scale to zero, right-size the database, move static assets to something that serves them cheaply — and re-measure. That usually closes the gap without a migration at all.

And if you do move: do not move to another free tier. You will be doing this again in eighteen months. Either pay a small amount somewhere stable, or self-host deliberately with your eyes open about the maintenance.

The trap that quietly ruins these projects: the spot price is not your price.

What you pay per unit is the spot price plus supplier margin, plus network and distribution charges, plus tax — and several of those components are themselves time-varying, often with a day/night split whose boundaries do not line up with the cheap spot hours at all.

So an optimiser fed raw spot prices can confidently move consumption from an hour that costs you less into one that costs you more, because it is looking at a component rather than the total.

Build your price series as the actual delivered cost per unit, with every component included, and optimise on that. It is a bit of work once and it changes the answer materially. If you have a negative or near-zero spot price, this is what tells you whether it is genuinely free or whether the fixed components mean it never really is.

Same applies in reverse if you export: the value of not-exporting is your export rate, not zero, so self-consumption has an opportunity cost.

On the developer-account email: make sure it is a shared address that a team monitors, not an individual's.

Every one of these providers announces deprecations, policy changes and credential expiries by email to that address, and the number of outages that were preceded by a warning nobody read because it went to someone who left is remarkable.

Same for the ownership of the app registration itself. If it sits under a personal account, you have a bus-factor problem hiding inside your login flow.

While you are in the console, note the expiry date of every credential in a calendar reminder a month ahead.