A platform team publishes one availability objective per service: 42 services, every target 99.9% over a calendar month, each computed from that service's own in-process metrics and reviewed in a monthly meeting. In two years two targets were missed and no release has ever been paused. What do you remove, what do you change, and what do you leave alone?

What is actually required

An objective exists to settle one recurring argument: is reliability good enough that the next sprint goes to features. That needs an indicator a user would recognise and a window short enough to act inside. Forty-two per-service targets provide neither, and the evidence is in the question: nothing has ever changed as a result of them.

What I would remove

The per-service targets on services with no user-visible journey. Independent 99.9% targets do not compose into a product promise. A checkout journey crossing eight of these services is roughly 0.999^8, about 99.2%, which is around 5.8 hours of journey failure a month while every single service reports success. A portfolio of green service objectives is entirely compatible with a product nobody can use, and that is the state this team is in.

The monthly meeting as the review mechanism. A budget read 30 days late cannot influence a decision; it arrives after the quarter it should have shaped. Keep the meeting for the trend, not for detection.

The one change that matters

Replace the calendar month with a rolling 28-day window. A calendar window forgives: a bad week ending on the 29^th is wiped on the 1^st, which quietly teaches everyone that risky changes belong at the end of the month. A rolling window never forgives, so the same bad week constrains behaviour for 28 days, which is the behaviour a budget is supposed to produce. The second-order effect is that the budget stops being a reporting artefact and starts being a running quantity someone can watch burn.

Then cut 42 objectives down to 4 to 6 journey objectives measured where the user is rather than in the process, and write the target in minutes: 99.9% of a month is 43 minutes and 12 seconds, which is a number a product owner can argue with, while "three nines" is not.

What I would leave alone

The two services that have actually breached. They have an indicator that moves and a team that reacted, so keep them as internal dependency objectives with named consumers even though they are not user journeys. Keep in-process measurement for the queue-draining workers too, where there is no client to measure from. It looks inconsistent next to journey measurement and it is still the only available vantage point.

When an objective is theatre

Two tests, both failed here. Has a release ever been held because of the budget, and can the product owner state the budget in minutes. If both answers are no, the number is decoration, and decoration has a cost: review time, dashboards to maintain, and the lesson that reliability figures are not to be taken seriously. The honest choices are to give the mechanism consequences or to delete it.

Common weak answers

• "Raise the targets to 99.99%." That is 4 minutes and 19 seconds a month, shorter than many deploys, bought at roughly ten times the engineering cost, for a measurement nobody acts on.
• "One objective per service is the standard practice." Published practice attaches objectives to journeys first and derives service targets from them, not the other way round.
• "Automate the monthly report." Faster theatre is still theatre.