An unmaintained mobile app backend — what breaks on the server when nobody looks after it

The app in the store is only half the product. Almost every mobile app talks to a server: it fetches data from it, signs users in, saves orders, sends notifications. Google Play and Apple make sure the app itself stays up to date and remind you with deadlines. Nobody but you looks after the server.

When we take over abandoned apps, the backend is usually in worse shape than the app. Nobody updated it because “it works”, and the owner finds out something is wrong on the day it breaks.

Why a backend outage is worse than an app bug

A bug in the app usually affects one version, one phone model or one flow. A server outage affects every user and every app version at once. You can’t fix it with a new store release, because the problem isn’t in the app.

To the user it looks exactly like an app bug: a spinning wheel, an empty screen, a “no connection” message. That’s why outages like this often show up first in store ratings — we cover that in our article on why apps get low ratings.

The SSL certificate — the most mundane of serious outages

A browser shows a warning for an expired certificate and lets you click through. A mobile app usually just stops connecting to the server. From the user’s point of view, the whole app stopped working overnight.

Until recently a certificate was renewed once a year, and that could be done by hand. That is changing. The CA/Browser Forum, the body that sets rules for certificate authorities and browsers, is shortening the maximum validity of certificates:

With certificates valid for 100 or 47 days, renewing by hand stops being realistic. You need automatic renewal and monitoring that checks it actually works. The second part matters: since 4 June 2025 Let’s Encrypt no longer sends emails about upcoming certificate expiry. If the automation quietly stops working, for example after a server configuration change, nobody gets a warning.

Certificate pinning

Some apps, especially in finance and healthcare, use certificate pinning: the app trusts only a specific certificate or key of the server. If the key changes when the certificate is renewed, every app version with the old key pinned stops connecting — and none of them will learn about an update, because they can’t reach the server.

Before you replace the certificate on the server, check whether the app pins it and what exactly it pins. The safer option is pinning the public key with a backup key prepared in advance. More on when pinning makes sense in our article on the most common mobile app security vulnerabilities.

The domain

A related problem: the API domain registered to a developer’s or agency’s private account, with a card that expired long ago. When the domain lapses, it takes down not only the API but also email and the website. Check who it’s registered to and when it expires.

A runtime that stopped getting fixes

The backend runs on a specific operating system and a specific runtime: PHP, Node.js, Python, Java. Each has a support cycle, after which it no longer gets security fixes. Some example dates:

To be fair: the server won’t stop working on that date. It stops getting patches, and every new vulnerability in that version stays open for good. The second problem is more down to earth: the longer you wait, the bigger the jump when you do update. Moving up one PHP or Node.js version is usually a few hours of work. Moving up four versions at once means changes to the code, libraries and framework, and sometimes a move to a new server, because the system is too old to install the new runtime on.

It’s the same mechanism we describe on the app side in our article on technical debt: small, regular updates cost less than one big one every few years.

Disk, logs and the database

These failures build up slowly and break suddenly:

• Logs fill the disk. A server that has been writing every request to a file for years without rotation runs out of space one day. The database stops accepting writes and the API starts returning 500 errors.
• The database grows, queries slow down. A query that took 50 ms with a thousand users takes several seconds with a hundred thousand, because an index is missing. The user sees a slow app, even though nothing in the app changed. How to track down causes like this is covered in our article on why a mobile app is slow.
• User files without limits. Photos, attachments and exports kept on the server’s disk instead of in file storage grow forever.

All three can be caught with simple alerts on disk usage, database size and API response time.

Backups nobody has ever restored

Backups running doesn’t mean the system can be restored from them. In takeovers we regularly find backups that contain only the database without the files, are stored on the same server they’re meant to protect, or have been failing for months with an error nobody reads.

The minimum worth having:

• backups stored off the production server, ideally with another provider or in another region,
• a test restore at least once a quarter, on a separate environment, with the time it took written down,
• clarity on who has access to the backups — they hold the same personal data as production, so the same rules apply.

The cloud bill

Cloud costs grow quietly: machines started for a test and never shut down, logs kept with no retention limit, data transfer, Firebase reads growing with the number of users. It’s worth going through the bill line by line once a quarter and setting up the budget alerts every major provider offers.

The more dangerous scenario is a bill nobody pays. A cloud account paid with the private card of a developer who left gets suspended after a few failed payments — and the whole backend goes with it. The billing account should belong to the company, with a company card and an address read by more than one person. It’s one of the points in our article on what to do when your developer disappears.

Keys and secrets that expire

Some of the credentials the backend uses have an expiry date:

• The APNs certificate (.p12) for iOS push notifications is valid for a year. Once it expires, notifications stop reaching iPhones while Android keeps working. The fix is a .p8 key, which doesn’t expire — details in our article on why push notifications stopped working.
• The Sign in with Apple client secret is a signed token that can be valid for at most 6 months. If the backend generates it by hand rather than automatically, Apple sign-in stops working once that period runs out.
• API keys for payment, maps or SMS providers may be rotated by the provider or expire with the contract.

It’s worth keeping all these dates in one register, along with where each key is used and who can renew it.

A minimal backend review

Most of this is set up once, and after that you only respond to alerts. Who is responsible for it is worth stating explicitly in your mobile app maintenance contract — otherwise each side assumes the other is handling it.

Summary

A mobile app’s backend gets no reminders from the stores, so it’s easy to forget while it works. The most common outages are mundane: an expired certificate, a full disk, an unpaid bill, an expired key. Each of them can be anticipated with simple monitoring and a register of dates, at a fraction of the cost of a single outage.

We take over and maintain mobile app backends together with the apps themselves — as part of mobile app maintenance or as a separate backend and API service. If you don’t know what state your app’s server is in, get in touch. We’ll check the app itself as part of a free app analysis.