Who Is Responsible When the Service You Rent Goes Down

The question this answers, and the one it does not

You have rented something — a database you do not install, a platform you do not size, a model you call rather than host. The bill arrives monthly and the thing works. Then one morning it does not, and the first fifteen minutes are spent on a question nobody wrote down in advance: is this ours to fix, or theirs, and how would we tell?

This is not the guide about an external interface changing shape over time; that argument is made at length in how to depend on an API you do not control, and it is about deprecation, versioning and reading responses tolerantly. It is not the guide about what a supplier does with your data, which is what to check before trusting an AI tool with your data covers. And it is not the choice between hosting something yourself and renting it, which self-hosted vs cloud AI tools weighs up. This one assumes the decision is made and the invoice is being paid, and asks the duller follow-up: of the work that still exists, which half is yours?

The line moves per service, not per supplier

The common mistake is to hold one belief about a supplier and apply it everywhere. But the boundary is a property of each individual service, and it slides as the service becomes more managed. Rent a bare machine and the operating system is yours to keep current. Rent the managed equivalent and it is not. Rent a finished application and what remains to you is accounts, permissions, configuration and content — which sounds like very little until an incident is caused by exactly one of those four.

So do this per service rather than per vendor, and do it for the handful you would genuinely miss rather than for everything. Five or six entries is usually the whole of it, and the work takes an afternoon.

Five lines worth writing for each one

Who applies updates, and on whose schedule. Who takes backups, and separately, who has ever restored one. Who holds the keys that protect the data, and what happens to your access if that key is rotated or lost. Who reviews the list of people and systems that can reach it. And who is expected to notice a problem first — you, from your own monitoring, or them, from theirs.

That last line is the one most often left blank, and it is the one that decides how a bad morning starts. If the honest answer is that you find out from a customer, that is a finding, not a failure; it just means the monitoring you assumed was somebody else's is nobody's.

Read what the promise excludes

Availability commitments are usually written as a headline figure surrounded by carve-outs, and the carve-outs are the informative part. Planned maintenance is very often excluded, which means a supplier can be unavailable to you, entirely legitimately, without the headline moving at all. Degraded performance may not count as unavailable unless it crosses a defined line. Problems caused by your own configuration are excluded, and the definition of your own configuration can be wider than you expect.

Then check what the remedy is. In most agreements it is a credit against future spend, calculated as a fraction of what you paid, and claimed by you within a window that starts when the incident does. That is worth knowing not because the money matters — it rarely does — but because it tells you what the commitment actually is. A promise whose remedy is a partial credit is a statement of intent with a price attached, not a guarantee that you will be serving customers.

Find out what you can do at three in the morning

The most useful question about a rented service is not who is at fault but what you can do while it is broken. Is there anything to try, or only somebody to call? If it is only somebody to call, then the substance of what you bought is the quality of that call: the hours it is answered, the route to a human who can change something rather than one who can log something, and whether your plan includes that route at all or only the one that promises a reply within a day.

Two more things belong in the same check. Can you see enough to diagnose your own half — logs, request traces, error detail — or does the supplier hold the only view of what happened? And is there a status source you can watch, with a history you can read, so that you are not deciding whether it is you or them by refreshing the page and guessing.

Watch for the day the line moves

Boundaries shift quietly during ordinary work. Migrating from something you operate to a managed equivalent hands half a page of responsibility to the supplier, and nobody reopens the document that says who does what. Moving a component into an arrangement where the supplier's software runs inside your own account moves it back, often to a team that has not been told it now carries capacity, upgrades and the first ten minutes of every incident. Adding a new supplier under an existing account inherits assumptions that were never checked for it.

The practical guard is a review date. Put one on the document, keep it to a single page, and check it whenever a service changes tier, moves account, or acquires a dependency it did not have before.

What good looks like

A page per team, listing the services that matter, with a named owner beside every line that says us and a contract reference beside every line that says them. Nothing about it is clever. Its whole value is that the argument about whose problem this is happened on a quiet Tuesday, in writing, rather than at the start of an outage when the answer is needed in minutes and the people who know are asleep.

The same question applies inside the building

Every argument above works unchanged between two teams in the same company. One team runs a platform, another builds on it, and the boundary between them is exactly as undocumented as the one with an external supplier — often more so, because nobody wrote a contract and everyone assumes goodwill will cover the gap. The internal version has a distinctive failure: the platform team believes the consuming team monitors its own use, the consuming team believes the platform team monitors the platform, and the thing that breaks is the join between them, which is monitored by neither.

The remedy is the same page with the same five lines. It costs an hour and it removes the most tiring conversation in operations, which is the one where two capable teams are each waiting for the other to start.