Main idea

The payroll database now lives in the customer's Azure environment. One morning, the application stops responding. Is it the vendor's engine, the customer's SQL Server database, a network rule changed the day before, a certificate, an IAM configuration, connection saturation, a quota, a latency problem?

Answering "the database is on the customer's side, not our problem" doesn't work. To the user who can't run payroll, it's the vendor's service that is down.

The contract moved a responsibility; perception didn't budge.

Why it matters

This imposes an obligation that follows not from the contract but from the situation: monitoring the externalized resource and its connectivity well enough to understand where an incident comes from. Not administering the customer's infrastructure, but having the signals — availability, latency, connection errors, saturation, health status.

It is a cost the arrangement doesn't surface at the moment it is negotiated, and which never goes away afterwards.

Nuances and limits

Monitoring doesn't make the vendor able to act: seeing the outage and being able to fix it are two different things.

And the obligation has a limit: beyond a certain point, monitoring the customer's whole environment amounts to operating it, which is exactly what the split was meant to avoid.

Open questions

• What level of monitoring is enough to diagnose without encroaching on the customer's operations?