Post-launch software support: what it is, and what 99.9% uptime hides

Launch day is the safest day your software will ever have. Everyone is watching. The team is still assembled. The code is fresh in someone's head. Every dependency is current.

Now move eleven months forward. The people who built it are elsewhere. Three libraries have shipped breaking changes. An API you call has deprecated a field. The error rate crept from 0.1% to 2% one deploy at a time, and nobody read the logs because nobody was assigned to read the logs. Nothing failed. It eroded.

Software does not rot loudly. No alarm goes off. A form takes four seconds instead of one. A report double-counts on the last day of the month. By the time a customer complains, it has been true for a while.

What "99.9% uptime" actually means

99.9% is about nine hours a year. The number matters less than its shape.

Nine hours spread as ninety-second blips at three in the morning is invisible. The same nine hours as one outage during your busiest trading day is a different year entirely. Both satisfy the same SLA, and only one of them costs you anything.

So the useful questions are not about the percentage:

1. 01What is being measured — the server responding, or a customer completing a purchase?
2. 02Who finds out first — us, or them?
3. 03What happens in the first five minutes?

An SLA is a number. Watching is an answer to those three.

Measuring the right thing

A server can respond perfectly while the thing your business depends on is broken. The homepage loads, the health check passes, and checkout has been failing for two hours because a payment provider changed a response format.

Monitoring that is worth paying for watches outcomes, not just processes:

• Did the transaction complete? Synthetic checks that walk the critical path end to end, not a ping.
• Error rate by operation, with a baseline, so a rise from 0.1% to 2% registers as an event rather than as noise.
• Response times at the slow end, not the average. The average hides the experience of the people having the worst one.
• The background work. Overnight jobs, scheduled syncs and queues fail silently more often than anything users touch.
• Integration health, per external system, because their outage becomes your incident.

Who finds out first

There is a hierarchy here, and most organisations are lower down it than they believe.

1. 01Nobody finds out. The problem is discovered weeks later in a reconciliation.
2. 02A customer finds out and complains.
3. 03Your staff find out and work around it without reporting it.
4. 04An alert fires to a channel nobody owns.
5. 05An alert reaches a named person who is expected to act.

The jump from four to five is the one that costs money and the one worth insisting on. An alert with no owner is a log entry with ambition.

The first five minutes

Decide this before you need it, because the middle of an incident is a poor time to discover that nobody knows who can authorise a rollback.

• Who is contacted, through which channel, and what the response window is.
• Who may roll back a release without asking permission.
• What gets communicated to your staff and customers, and by whom.
• Where the record of the incident goes afterwards, so the same cause does not recur quarterly.

Dependencies and security patches

This is the least visible part of support and the one with the clearest consequences. Every system is built on libraries, and some of those ship security fixes with a clock on them.

The arrangement needs to say how vulnerabilities are detected, how quickly routine and urgent patches are applied, who tests that nothing broke, and whether this is covered or billed. Unpatched dependencies are the most common route into an application that was otherwise built carefully.

What a support agreement should actually say

Most support contracts describe hours of availability and a response time, which is the easy half. The half that decides whether the software is healthy in year three is usually missing.

• A named owner on each side, and what happens when either leaves.
• What is monitored, specifically, and where you can see it yourself.
• Severity definitions written in business terms — orders cannot be placed, rather than service degraded.
• Response and resolution expectations per severity, separately. Acknowledging quickly is not fixing.
• Patch cadence for routine and urgent, and who pays.
• Backup frequency, retention, and the date restoration was last tested. An untested backup is a belief.
• What happens at the end, including data export and handover of accounts.

That list is more or less what we mean by the third word in build, deploy, watch, and it is described in full under deployment, monitoring and support. The gap it closes is the one that produces most of the failures in why ERP implementations fail.

If you have inherited something nobody is watching

This is common and recoverable, and it does not require rebuilding anything. In rough order of value for effort:

1. 01Find out whether backups exist and restore one into a test environment. Do this first; everything else is less urgent than discovering it does not work.
2. 02Put a synthetic check on the single most important path the business depends on, and route the alert to a named person.
3. 03Get a dependency vulnerability scan running, even a free one, so the list of known problems exists.
4. 04Confirm you control the hosting accounts, domains and certificates. Expired certificates are a classic self-inflicted outage.
5. 05Write down who does what in the first five minutes.

If you would like a second pair of eyes on something already live, that is a conversation worth having before it becomes an incident — get in touch.