Contents (7 sections)
“We want something reliable.” It is a fair request, but the word “reliable” means nothing until it is turned into figures and commitments. A reliable application is not one that never goes down; that does not exist. It is an application whose expected behaviour is known, whose deviations are measured, and whose service is brought back within guaranteed times. Here is how we break it down at Sanfytech.
Defining reliability: uptime, RTO, RPO #
Three indicators are enough to frame a serious discussion about reliability.
Uptime (or availability) measures the percentage of time the service is working. The RTO (Recovery Time Objective) is the maximum acceptable time to bring the service back after an incident. The RPO (Recovery Point Objective) is the maximum amount of data you can afford to lose, expressed as time: an RPO of one hour means that, at worst, you lose an hour of data.
Until figures are put on these three lines, “reliable” remains wishful thinking.
What a 99.9% service level means in practice #
A service level agreement at 99.9% uptime means about 8 hours 45 minutes of tolerated downtime per year, roughly 43 minutes a month. At 99.99%, you drop below one hour a year. The difference between these two figures is not cosmetic: it means redundant architecture, cost and complexity.
The classic trap is promising 99.99% without paying the technical price. Our approach is to offer the service level that truly fits your use (an internal tool and an online sales platform do not have the same requirements) and to put it in black and white, with what happens if we miss it.
A service level commitment is not a promise never to go down. It is a written commitment on how fast we get back up, and on what happens to you if we fail to.
Monitoring and alerting: see it before you suffer it #
Reliability starts with visibility. We continuously monitor availability, response times, CPU, memory and disk usage, and application errors. The goal is not to pile up graphs, but to trigger an alert at the right moment, ideally before the user notices anything.
A good alerting rule detects degradation (latency creeping up, a disk filling up) and not only outright failure. That is the difference between stepping in at 3 am on an incident under control and discovering the problem at 9 am with customers online.
Backups and disaster recovery #
A backup that has never been restored is not a backup, it is a hope. We back up daily, encrypted, and we test restores regularly. The disaster recovery plan documents precisely what to restore, in what order and how quickly, so nobody improvises on the day it really counts.
On-call support, response and restoration times #
When a critical incident happens outside working hours, on-call support takes over. Two commitments structure it: the guaranteed response time (GTI in French contracts), within which someone takes charge of the incident, and the guaranteed restoration time (GTR), within which the service is restored. Both figures are contractual: they turn “we will deal with it” into a measurable commitment.
Our reliability checklist #
- Define target uptime, RTO and RPO before talking technology.
- Write down the service level, and also what happens if it is not met.
- Alert on degradation, not only on failure.
- Test that backups can be restored, not just that they exist.
- Document the disaster recovery plan and rehearse it periodically.
- Set response and restoration times in writing, with real on-call support behind them.
In short #
“Reliable” becomes useful once it is turned into measurable indicators and written commitments: a target uptime, an RTO and RPO you stand by, monitoring that alerts early, tested backups, a documented disaster recovery plan and on-call support with guaranteed response and restoration times. That is exactly what our managed services cover: one party accountable, no passing the buck.
To put your application under monitoring and rely on clear commitments, see our managed services, day and night or contact us: first conversation free, reply within 24 working hours.
