Uptime, monitoring and SLAs: how to keep your app online

How do you keep your app online and spot outages before customers do?

Keeping an app online is not luck. It rests on three layers: monitoring that catches a problem within minutes, resilient hosting that absorbs traffic spikes and lets you undo any release, and a service level agreement (SLA) that tells you exactly what your hosting provider promises. A store or clinic owner does not need to be an operations engineer, but they do need to know these layers exist and ask about them.

The familiar story: checkout breaks on Eid night and you only find out two hours later from an angry WhatsApp message. In those two hours orders were lost, support messages piled up and some customers went to a competitor. Good monitoring turns that into an alert on your phone within two minutes, and rollback undoes the faulty release in one.

An outage you discover is a technical incident. An outage your customer discovers is a trust problem.

What does 99.9% uptime actually mean?

Uptime is the share of time your app is available during a measurement period, usually a month. The numbers look close together until you convert them into minutes. These are approximate figures for a 30-day month:

Timing matters too. Forty minutes of maintenance at dawn on a Tuesday is very different from forty minutes in the first hour of a White Friday sale. Ask your provider when scheduled maintenance happens and whether it counts against the uptime figure.

What should you monitor?

A common mistake is to monitor only 'is the server up?'. The server can be up while payments fail because of an expired key, or sign-in is broken because the OTP messaging service is not responding. Monitor the customer journey, not the machine.

Where should alerts go?

• A channel someone actually sees: a phone notification or call, not an email read tomorrow morning.
• A clearly named person on call at all times, especially in peak seasons and on the weekend.
• A simple status page or a ready message to tell customers if the issue drags on.
• Few, meaningful alerts: too many false alarms teach the team to ignore the real one.

Why apps go down, and the fix for each cause

Once you know the common causes, you know where to spend effort. In small projects most outages do not come from a data center failing. They come from everyday things:

That is why you keep staging separate from production and maintain backups and a recovery plan. On Fanann hosting, autoscaling, daily backups and instant rollback come with the hosting, and you still decide when to release.

How to read a service level agreement (SLA)

An SLA is a contract that defines what the provider commits to. The big percentage is only the first line; the details are what matter. When you review any SLA, or write one for your own customers if you sell software, look for these points:

• How downtime is measured: from where, at what interval, and whether severe slowness counts as downtime.
• Exclusions: scheduled maintenance, outside services failing, bugs in your own code.
• Compensation: usually a credit on your next invoice, not cover for lost business. Read it realistically.
• Support response times: how many minutes until a person responds to a critical incident, and whether support covers your local weekend.
• Data and backup location: where data and backups live, and the target time to restore.
• How to claim: many agreements require you to request credits within a set period.

For companies and public bodies that need a formal SLA, in-country hosting and audit logs, see Fanann for enterprise. For where your data should live, read hosting your app's data in Saudi Arabia.

The incident plan: what to do when your app goes down

1. 1
   Confirm the outage

   Open the app on a different phone and network, and check your monitoring. Is everything down, or just one part such as checkout?

2. 2
   Ask what changed

   If there was a release in the last few hours, roll it back first and investigate later.

3. 3
   Check outside services

   Payment gateway, messaging provider, maps. If the problem is theirs, switch on your fallback and tell customers.

4. 4
   Talk to customers

   A short, honest message in the app or on social accounts beats silence. Do not promise a time you do not know.

5. 5
   Write a short post-incident note

   What happened, when it was detected, how long it lasted, and what will prevent a repeat. Three paragraphs are enough.

Peak-season readiness checklist

Gulf traffic peaks at predictable times: Ramadan nights, the days before Eid, White Friday, Saudi National Day and Founding Day, and the Dubai Shopping Festival in the UAE. Two weeks before each one:

• Freeze large releases during peak week and ship only essential fixes.
• Run the full order path on a real phone: sign-up, cart, payment with mada and Apple Pay, notification.
• Confirm autoscaling and plan limits, check backups run, and test a restore.
• Name someone on call for each shift, especially after iftar and late at night.
• Prepare an outage message in Arabic and English and a payment fallback.
• Check SSL certificate and domain expiry dates.

For the commercial side of the season, read White Friday prep for Saudi stores, and if your app is growing, read when your AI-built app grows. Your next step: set up outside monitoring on three pages today and decide who receives the alerts.

Frequently asked questions

Terms in this article