Managed support agreements are sold on reassurance: round-the-clock coverage, expert engineers, quick response. The summary page rarely lies, but it does leave things out. The clauses that decide your experience on a bad night sit further down, in service schedules and definitions. This guide takes a question-and-answer approach to the terms of a managed DevOps support agreement, covering the points that most often surprise customers. It is general information, written to help you read the document, not to interpret it for you.<\/p>\n
Often less than it sounds. Round-the-clock coverage usually means someone can receive your request at any hour. What the agreement promises about the response is a separate matter. Look for a defined target for acknowledging a ticket and, separately, for starting work on it. Check whether those targets apply at all hours or only during business time for lower-priority issues.<\/p>\n
This is one of the most consequential paragraphs in the document. A complete outage of a production system might qualify as the highest severity, while a degraded service may be classed lower, with a slower response. Read the definitions, and note who assigns the level. If the provider has the final say, confirm there is a process to escalate if you disagree.<\/p>\n
Every agreement has exclusions. Typical examples include problems caused by changes the customer made, third-party software outside the supported list, outages of upstream cloud providers, and work that counts as a “project” rather than support. List the exclusions and compare them with how your systems really run. If your stack includes a tool the agreement does not cover, you may be paying for a service that stops where your risk starts.<\/p>\n
The answer is usually a service credit, a discount applied to a later invoice. Check how the credit is calculated, whether it is capped, and whether you must claim it within a specific period. Some agreements make credits the only remedy, which is an important phrase to notice. It can limit what you may seek for a serious failure.<\/p>\n
When an engineer from the provider applies a change and something breaks, the liability clause matters. Look for a cap, commonly linked to fees paid over a period, and for exclusions such as loss of profit. Also check whether the provider carries insurance and whether you must approve changes in advance. Approval workflows are not only good practice; they also affect where responsibility lies.<\/p>\n
Many agreements run for a fixed term and renew automatically. Find the length of the term, the notice required to stop renewal, and the form that notice must take. Note any right the provider has to change prices at renewal and how much warning it must give. Record the cut-off date where the whole team sees it, the day the agreement is signed.<\/p>\n
Some agreements allow the provider to update service descriptions or policies by posting them online. If so, find out how you will be told and whether you may end the agreement if you object. A clause allowing unilateral change with no exit is worth discussing before signing.<\/p>\n
Exit is when many customers discover gaps. Ask what the provider holds on your behalf, including credentials, runbooks, monitoring configuration and logs. The agreement should say how these are returned, in what form, how long it takes, and whether any fee applies. Also check that administrative access you granted will be revoked, and by whom.<\/p>\n
Good support depends on shared understanding of how systems are built and operated. The principles discussed in core ideas behind dependable software delivery<\/a> can guide the conversation: if your team practises small, frequent releases, the agreement should not assume quarterly change windows. Mismatches between the contract and practice generate friction later.<\/p>\n Similarly, teams moving from manual operations towards automation will want clarity about how the provider handles infrastructure code. The shift described in the move from scripted infrastructure towards SRE thinking<\/a> raises questions about repository access, review responsibilities and who owns the automation the provider writes.<\/p>\nDo we need a lawyer to read it?<\/h2>\n