Support terms say how fast a vendor responds when the tool breaks, and the numbers are easy to misread. Check how severity is defined, whether the time is for first response or for a fix, which hours apply, who you can escalate to, and what remedy you have if targets are missed. Then match it to your risk.
Response is not resolution
A "one hour response" means someone acknowledges your ticket within an hour. It does not mean the problem is fixed. Look for separate commitments:
- Acknowledgement: a human or an auto reply?
- Initial response: a person who has read the issue.
- Workaround or update cadence: how often will you hear from them on a severe problem?
- Resolution target: often not promised, which is reasonable, but ask about it.
Severity definitions
Who decides the severity, you or the vendor? A severity one that only the vendor can assign is weaker than one you can raise. Ask for definitions with examples: tool down in production, scans failing across all repositories, wrong results, a question.
Hours and channels
- Business hours in whose time zone?
- Is weekend and holiday cover available for the top severity?
- Which channels count: email, portal, chat, phone?
- Is there a status page with incident history?
If your pipelines run around the clock, a tool that only supports one region's business hours is a risk for your release schedule.
Escalation
Ask for a named escalation path: support, then a duty manager, then an executive contact. Ask whether you get a named technical contact or a pool. Note what happens when the problem is a security issue in the vendor's product itself. There should be a way to report it that is not the general support queue, ideally a published security contact.
What happens if they miss
Look at the remedy. Common ones are service credits, which compensate a little, and a right to terminate after repeated misses, which matters more. Ask whether chronic failure gives you the right to leave without penalty.
Incident communication
Ask how you will be told about a vendor incident that affects you, how soon, and whether a written post incident summary is promised for severe events.
Align with your needs
Write down the three failures that would hurt you most: scans not running before a release, a gate blocking all merges, a leak of your data. Check each against the support terms. If a failure has no matching term, that is where to negotiate.
Fail safe in your pipeline
Whatever the contract says, design for vendor downtime. Decide whether a gate fails open or closed, who can override it and how that is logged. See the pipeline outage plan for LLM vendors for the same pattern.
Quick check
Is a service credit enough?
It is a small remedy. A right to terminate after repeated misses is worth more.
Do we need twenty four hour support?
Only if an outage of the tool would stop releases or response outside business hours. Check how you actually work.
Last reviewed: 19 October 2026.
