My app stopped working and I have not changed anything. What could have expired?

There is a sentence that comes up in almost every emergency I get called into, and it is said apologetically, as though it is an admission of not knowing: but nothing changed.

It is usually true. And it is the most useful thing anybody says all day, because it rules out most of what you would otherwise spend the afternoon looking at, and points at a category of failure that people who have not been through it do not know exists.

Some things in a running application expire. Not because anybody did anything, but because a date arrived. No deploy, no error in your code, no signal of any kind until the moment it stops. This is a tour of the ones that actually catch people, starting with the one that is catching a lot of people right now.

Sign in with Apple, which dies quietly at six months

If your app offers "Sign in with Apple", this is coming for you, and the timing is worth understanding.

Most identity providers give you a secret that lasts until you change it. Apple does not. There is no permanent client secret to copy — you generate one yourself, signing it with a private key file Apple gives you, and the resulting token has a hard maximum lifetime of just over six months. When that window closes, it stops working. Apple sends no warning. Nothing in your backend's dashboard indicates anything is wrong. There is no error until a real user tries to sign in and cannot.

The symptom is specific enough to be diagnostic. Web sign-in fails, usually with a message about an invalid client, while sign-in inside a native iOS app carries on working perfectly. If somebody tells you Apple login is broken and somebody else tells you it works fine, they are probably both right, and you have just found your answer.

The reason it is worth writing about in August 2026 rather than in the abstract is arithmetic. A great many apps shipped Apple login in the first half of this year. Six months later is now.

The fix: regenerate the secret and redeploy it, which takes about fifteen minutes once you have done it once. The official advice, from more than one direction, is genuinely to put a recurring reminder in a calendar — which tells you that even the people who designed it consider this a human process rather than an automatic one.

Certificates, domains, and the renewal nobody owns

Certificates expire, usually every ninety days now, and if you are on a managed host this is handled and you will never think about it. That is a real benefit and I do not want to manufacture anxiety about it.

What is not handled is anything outside that host's scope. A certificate on a service you run somewhere else. A signing certificate for an app store. A domain registered at a registrar whose account email is a personal address that stopped being checked when somebody changed jobs.

The pattern is consistent: the renewal that fails is always the one that sits between two owners. The host renews what it manages. Your developer manages what they set up. The thing in the gap belongs to nobody, and it is discovered on the day it lapses.

The card on file

Unglamorous and extremely common. A card expires, a subscription fails, a service degrades or stops, and the notification goes to whichever address was used at signup — frequently the developer who set the account up rather than the person who owns the business.

This is worth an hour of anyone's time. Go through every service the app depends on and check whose card is on it and whose email receives the receipt. If either answer is somebody who no longer works on this, fix it now.

The deprecations currently on the calendar

Platforms retire things on published schedules. None of these appears in your application logs; each simply stops on the day. What follows was accurate in August 2026, and dates of this kind move — verify with the vendor rather than trusting a blog post, including this one.

Runtime versions. Node 20 is scheduled for deprecation on Vercel from the start of October 2026. AI-built projects are unusually exposed here because the runtime version was written into the project configuration when it was created and has never been thought about since.

Database versions. Support for Postgres 14 ended in July 2026 on Supabase. Older projects created by a tool are exactly the ones nobody has upgraded.

Extension version pinning. Since early August 2026, Supabase no longer honours an explicit version in an extension creation statement — it installs the current version and warns. If an AI assistant wrote a migration pinning a version, that migration now quietly does something other than what it says.

Key formats. Supabase has announced that the long-standing anonymous and service keys will be deprecated in favour of a new format, with the changeover indicated for the end of 2026. Every app built on the platform will need its keys rotated. When I searched for people discussing this in mid-2026 I found essentially nobody, which is the interesting part: it is a dated, certain break that almost no one has started on.

Client library requirements. The official Supabase JavaScript client is set to require a newer TypeScript from the start of 2027, which will strand projects pinned to older tooling.

And one that is not a break but a decision with a deadline. From 9 September 2026, Lovable's documentation states that content from Free and Pro accounts — prompts, code, project files and outputs — may be used to train its models unless the account holder opts out, with the setting in account preferences. Business and Enterprise accounts are excluded. Opting out before the date prevents the use entirely; after it, only future use stops. I will flag honestly that the company's privacy policy and its documentation did not read consistently on this when I checked, so confirm it yourself rather than taking my word for it. But if you would rather your code was not in that pool, the date is real and it is close.

API versions pinned to a moment you have forgotten

This one is subtle and produces some of the strangest bugs.

When you create an integration, the payloads it sends are shaped by whatever version of that provider's interface was current at the time — or by whatever version your library pins. Months later you upgrade a library, or a provider makes a change, and now the messages arriving are shaped slightly differently from the ones your code was written against. Nothing errors. A field is simply absent, and something downstream silently does nothing.

The reason this belongs in an article about expiry is that the trigger is temporal rather than causal. Nobody changed the integration. Time passed on both sides of it.

The credentials nobody remembers are credentials

A short list, because each of these has caught somebody I have worked with.

Refresh tokens for third-party integrations expire, and when they do the integration stops silently — the calendar sync that stopped syncing, the mailbox connection that stopped connecting. Usually there is no alert because from your app's point of view nothing failed, it just stopped being asked.

Webhook signing secrets are per-endpoint. Recreate the endpoint and you have a new secret, and events start arriving that your code cannot verify. This is a five-minute outage that reliably takes two hours to find.

Idempotency keys on payment providers are typically prunable after twenty-four hours, so anything that retries over a longer horizon — a dunning process, a weekly batch — needs its own record rather than relying on the provider's.

Personal access tokens used in scripts and deploy pipelines often carry a maximum lifetime. The deploy that has worked every week for three months fails on a Tuesday for no reason anyone can see.

How to find yours in an afternoon

You do not need tooling for this. You need one page.

List every service the app touches. Do this from the bills and the inbox rather than from the code, because the credentials that expire live in dashboards, not in the repository. Card statements and a search for signup confirmations will find services that reading the source never will.

For each one, write down four things: what it is, where the credential lives, when it expires or renews, and who receives the notification. If any of those four is unknown, that gap is your first job.

Put every date in a shared calendar with two weeks' notice. Not a personal calendar. Something that survives somebody being on holiday.

And write two lines of instruction beside each. Where the secret lives and what regenerates it. This is the part people skip and the part that pays. These things always come due at the moment you have the least context, and two lines is the difference between ten minutes and a ruined afternoon.

The diagnostic worth memorising

When something breaks and nothing changed, ask one question before anything else: is the failure partial?

A bug usually breaks a feature for everybody. An expiry breaks one path and leaves its siblings alone, because credentials are scoped to paths. Apple login broken but Google login fine. One integration dead and four healthy. Web sign-in failing and the app working. That asymmetry is not a coincidence to be explained away — it is the shape of the answer, and it tells you which credential to go and look at.

The second question is simply whether anyone deployed anything in the window. If the honest answer is no, believe it. In this category, "nothing changed" is not an unhelpful answer. It is the diagnosis.

If you would rather have someone do the pass

Building the register is genuinely doable yourself and I would encourage it. Where people get stuck is not the writing down — it is that they cannot see what is missing, because the services nobody remembers are by definition the ones that do not come to mind.

I do a Production-Ready Audit that includes this: every service the app depends on found from the outside rather than from your memory, every credential and its expiry identified, notification paths checked against who actually reads them, and a written register handed over at the end that you keep. From $499, back in five to seven days.

You are also welcome to send me the list you have made and I will tell you what is usually missing from a list like that, at no charge and with nothing attached.

The deployment and reliability work is described on the launch and deployment page. If something is broken right now and you are still working out what it is, start with my app is down and I do not know why. If the failure appeared the moment you went live rather than months later, that is a different cause and it is in why your app works in preview but breaks in production. And the backend equivalent of an expiry — a database that goes to sleep on a schedule rather than a credential that lapses — is in Supabase paused your project.