Uptime checks from outside
Your application is requested from the public internet on a short interval, from more than one location. If it stops answering, that is detected in minutes rather than whenever someone next visits.
Reliable
It stays up, and someone is watching.
Anyone can build you an application. The hard part is keeping it alive — and that is the part we sell.
When your application breaks at two in the morning, you are not the monitoring system.
The difference between software that exists and software you can build a business on is entirely about what happens on the bad days. A deployment that takes the site down during a demo. A database that fills up. A third-party service that changes without warning. A backup that turns out never to have worked. None of this is exotic — it is the ordinary weather of running software, and surviving it is a discipline rather than a feature.
Watching
You should learn that your application is down from us, not from a customer.
Errors alert a person, not a dashboard
Application errors are captured with the context needed to reproduce them and routed to whoever is on call. A dashboard nobody is looking at is not monitoring.
Performance watched before it becomes an outage
Response times, slow database queries and queue depth are tracked over time. Most outages announce themselves as a gradual slowdown for days beforehand, if anyone is reading.
Cost and quota alarms
A runaway process or an abusive script shows up as a spending alert rather than as a surprise invoice at the end of the month.
A status page you can point customers at
When something is wrong, your customers get a page that says so, instead of your inbox getting the question forty times.
Recovering
A backup you have never restored is a hypothesis, not a backup.
Automated daily backups, retained
Your database is backed up on a daily schedule with point-in-time recovery within the retention window, stored separately from the running system.
Restores tested, not assumed
Backups are periodically restored into a scratch environment to prove they work. This is the step almost everyone skips, and it is the one that matters.
Rollback as the first response
Every release can be reverted to the previous version. When a deployment misbehaves the first move is to put the working version back, then diagnose calmly.
Rebuildable infrastructure
The environment your application runs in is defined as code, so it can be recreated rather than remembered. Recovery does not depend on one person's notes.
Changing without breaking
Staging first, always
Changes are exercised on a copy with realistic data before they touch the version your customers use.
Automated checks on every change
The test suite runs before anything ships. It is not there to prove the code is perfect; it is there to catch the change that quietly broke something unrelated three screens away.
Deployments without downtime
New versions are brought up alongside the old and traffic is moved across. Your users do not see a maintenance page because you shipped a feature.
Scheduled maintenance, announced
Where work genuinely requires a window, you are told in advance and it happens when your users are asleep rather than when they are buying.
The specifics
Operational commitments
Specific targets are agreed per application — a marketing site and a payment flow do not deserve the same promise. These are the defaults.
| Item | What you get |
|---|---|
| Uptime target | 99.9% monthly for production applications |
| External checks | Every minute, from multiple regions |
| Error tracking | Continuous, alerting to an on-call person |
| Backups | Daily automated, stored separately, 30-day retention |
| Point-in-time recovery | Within the retention window |
| Restore testing | Periodic, into an isolated environment |
| Rollback | Any release, to the previous version, in minutes |
| Deployment | Zero-downtime; staging gate before production |
| Status page | Public, per application |
| Incident report | Written account after anything customer-visible |
Questions people ask
What does 99.9% actually mean?
About forty-three minutes of unavailability in a month. It is an honest number for a well-run application, and it is deliberately not the 99.999% that sounds better and is quietly untrue for almost everyone who claims it.
Is someone genuinely awake at 3am?
Alerts reach a person on call rather than a queue that is read at nine. What that person can do at 3am depends on the failure — restoring service comes first, the explanation comes in the morning.
What if I need a stronger guarantee than the default?
Then we should talk about it specifically. Higher availability is achievable and it costs more to run, so it is a decision you should make deliberately rather than one we should assume.
How do I know the backups work?
Because they get restored on a schedule into an environment built for the purpose, and you can ask for the result of the last test.