What Happens When Your Licensing Server Goes Down

Here is an uncomfortable question for anyone selling a desktop app: if your licensing server went down right now, for an hour, how many of your customers could still open the app they paid for? For a lot of apps the honest answer is “none,” and that is a design flaw worth fixing before it bites.

The single point of failure you did not mean to build

Most licensing starts online. The app sends a license to a server, the server checks a database, it replies valid or invalid. Simple, correct, easy to ship.

It also quietly makes your licensing server a launch-time dependency for every customer. The app cannot decide whether it is licensed without that server answering. So the day the server is slow, or the database is locked during a migration, or the deploy goes wrong, or the host has an incident — every customer who tries to open the app at that moment fails.

They did nothing wrong. They paid, they have a valid license, and the app will not open. From their side it is your app being broken, and “the licensing server was down” is not an explanation that makes them feel better. You built a single point of failure and attached your entire user base to it, probably without ever deciding to.

Offline-first removes the dependency

The fix is architectural: the licensing server must not be on the launch path.

That is exactly what offline license validation achieves. The license is a cryptographically signed lease. The app ships with a public key and verifies the lease locally — it confirms the signature in memory, with no network call. Launch no longer depends on anyone’s server being up. It depends only on the math, which never has an outage.

The server still has a role — issuing licenses, processing revocations — but it is consulted periodically, in the background, not on every launch. Move the server off the critical path and an outage stops being customer-facing. The licensing service can be down for an hour and not one customer notices, because not one customer’s launch was waiting on it.

Fail open, not closed

Offline-first introduces one decision you must make deliberately: when the app does try a periodic background revalidation and cannot reach the server, what should it do?

There are two choices. Fail closed: treat unreachable as unlicensed and lock the app. Fail open: keep running on the last valid license and try again later.

For a licensing system, fail open is correct. A failed revalidation almost always means a network problem or an outage on your side — not a customer who stopped paying. Failing closed punishes a paying customer for your infrastructure’s bad day. Failing open keeps them working and simply retries; the cached signed license is still cryptographically valid, so you lose nothing by trusting it a little longer.

The cached lease has a generous validity window, the app keeps working through transient failures, and revocation still lands once connectivity returns. You give up instantaneous revocation — a refunded user offline through your outage stays unlocked a bit longer — and in exchange every honest customer is immune to your downtime. That is the right trade.

What it looks like

In code, resilience is the absence of special handling — there is no “server down” branch on the launch path, because launch never calls the server:

import KeylightSDK

// Verifies the cached signed lease locally; revalidation is background + best-effort.
await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:     enablePaidFeatures()
case .trial(let d): showTrialBanner(daysLeft: d)
case .expired:      showRenewalPrompt()
case .invalid:      showActivationSheet()
}

checkOnLaunch() resolves from the local signed lease. If a background revalidation fails, the SDK keeps the last valid state — fail-open by design — and retries later. Your app has no outage-handling code because, from the app’s point of view, the server being down is a non-event.

The test to run

Here is a concrete exercise: imagine your licensing server is down for one hour during your busiest time. Walk through what each customer experiences. If the answer is “the app still opens, nobody notices” — your licensing is designed correctly. If the answer is “everyone is locked out” — you have a single point of failure, and the fix is to get the server off the launch path.

A licensing system should never be the reason a paying customer cannot open their app. If you have an availability story worth a deeper post, send us your feedback.