Questions to Ask an AI Video Vendor About Uptime, SLAs, and Reliability

Quick answer: Ask an AI video vendor exactly what service is covered, how availability is calculated, which failures and maintenance periods are excluded, how incidents are reported, and what remedy applies. Then test the SLA against your workflow. A dashboard that loads while every render fails may meet a narrow “uptime” promise but still stop production.

An uptime percentage is not a reliability plan

An AI video service is a chain: sign-in, project editing, asset upload, generation queues, model or rendering dependencies, storage, export and sometimes an API. The contract may measure only one part of that chain.

NIST describes service-level objectives as measurable elements within a service agreement and stresses that appropriate metrics are essential. The UK National Cyber Security Centre (NCSC) adds a practical warning: contractual availability commitments may provide compensation, but an SLA does not prevent outages if the service design is unsuitable.

Start with the business outcome. Do you need creators to edit projects during office hours? A dependable API for overnight batch generation? Delivery before a regulated training deadline? The right questions follow from the consequence of failure.

15 questions to ask an AI video vendor

1. What is the “service” in your availability calculation?

Ask whether the metric covers:

• authentication;
• the web editor;
• generation submission;
• queue processing;
• rendering and export;
• APIs and webhooks;
• asset storage and retrieval;
• administrator functions.

Request separate objectives for critical components if one blended number would hide a production-blocking failure.

2. What counts as unavailable?

Does “unavailable” mean the endpoint returns an error, or also that requests time out, queue indefinitely or produce unusable output? Define thresholds: for example, the proportion of generation jobs that fail for a platform reason, or a maximum queue-to-completion time for a specified workload.

Output quality is not normally an availability metric. Keep a separate acceptance process for fidelity, accuracy and editability.

3. How is uptime calculated?

Ask for the formula, measurement window, data source, polling frequency and time zone. Monthly availability can conceal one long outage or several disruptive incidents. Clarify whether the vendor measures server responses, customer-visible transactions or both.

Do not convert an availability target into an assumed downtime allowance without reading the exclusions and calculation method.

4. Which exclusions apply?

Common exclusions include scheduled maintenance, emergency maintenance, customer configuration, internet failures, third-party services, force majeure and preview features. The issue is not whether exclusions exist, but whether they are precise and allocate risk sensibly.

Ask whether failures of the vendor’s cloud, model, voice, stock-media or payment suppliers are excluded. From your perspective, a dependency failure can still stop production.

5. How is scheduled maintenance handled?

Confirm notice period, maintenance window, likely impact, communication channel and whether urgent changes follow a different process. If your team operates across time zones, a “low-traffic” window for the vendor may be peak time for you.

6. What service levels apply to generation jobs?

Measure the workflow, not just the website. Useful indicators may include:

• successful job completion rate;
• queue latency and total generation time by job class;
• export success;
• API error rate;
• webhook delivery or retry behaviour;
• recovery of projects after a failed job.

These should be objectively measurable and tied to defined workloads. A vendor should not promise one render time for every video length and complexity unless it can support that commitment.

7. How are severity levels defined?

Read the definitions. “Critical” should reflect business impact, such as all production blocked, data inaccessible or a security incident affecting customer data. Establish who can declare severity and whether the vendor can downgrade it without agreement.

8. Is the target a response or a resolution?

“Response within one hour” may mean only acknowledgement. Ask for targets covering:

• acknowledgement;
• initial qualified human response;
• investigation update cadence;
• workaround;
• restoration;
• root-cause analysis.

Resolution times are harder to guarantee, but the contract can still define escalation and communication expectations.

9. When is support available?

Specify hours, holidays, time zone and channels for each severity. If production runs overnight or at weekends, weekday email support may not match the risk. Read our guide to enterprise AI video support models before paying for a premium tier.

10. How will we learn about incidents?

Ask about the public status page, named contacts, in-product notices, email distribution lists and API or webhook options. The NCSC recommends pre-planned incident processes, a defined customer reporting route and an agreement on how and when the provider will tell you about an incident affecting your data.

11. What evidence of reliability can you provide?

Request a defined period of historical availability and incident information, with the same calculation used in the proposed SLA. Ask for:

• status-page history;
• material incident summaries;
• restoration and post-incident review process;
• capacity and load-testing approach;
• backup and recovery scope;
• relevant independent assurance reports.

Evidence should be current and scoped to the service you will buy. A certificate is not a substitute for understanding the architecture and controls.

12. How resilient are the service and its dependencies?

The NCSC advises customers to understand resilience across data centres, availability zones or regions and the impact of dependent services. Ask what is redundant, what fails over automatically, what requires manual intervention and what the customer must configure.

For your own workflow, decide whether you can queue work, retain editable source material, export intermediate assets or use a documented fallback.

13. What is the disaster-recovery commitment?

Ask for recovery time objective (RTO) and recovery point objective (RPO), their scope, and evidence that recovery is tested. RTO concerns the target time to restore; RPO concerns the acceptable point to which data may be recovered. Ensure both cover projects and customer assets, not merely account records.

14. What remedy applies if a target is missed?

Service credits are common. Clarify:

• whether credits are automatic or must be claimed;
• the claim deadline and required evidence;
• caps;
• which invoice or renewal receives the credit;
• repeated-failure termination rights;
• whether credits are the exclusive remedy.

A small future credit may not address a missed launch. Your operational fallback often matters more.

15. How do we leave or continue operating?

Confirm export formats, data retrieval period, deletion process, assistance, fees and access after termination. Include editable project data where technically available, not only final MP4 files. Procurement should cover exit before dependence grows.

Score the answers with the RELIABLE framework

Use a 0–2 score for each category: 0 absent, 1 partial, 2 clear and evidenced.

R, Relevant scope

The commitment covers the user journey and components your team depends on.

E, Explicit metrics

Definitions, formulae, thresholds, windows and exclusions are unambiguous.

L, Live communication

There are usable incident channels, update intervals and named escalation routes.

I, Incident readiness

Severity, response, restoration, post-incident review and security notification are defined.

A, Architecture and recovery

The vendor explains dependencies, resilience, backups, RTO, RPO and tests.

B, Business remedy

Credits, repeated-failure rights and termination provisions reflect impact.

L, Long-term evidence

The vendor supplies relevant history and ongoing reporting.

E, Exit readiness

Your content and records can be retrieved, transitioned and deleted on agreed terms.

A score helps comparison, but do not hide a deal-breaker inside a total. If a critical data-recovery requirement scores zero, a strong status page elsewhere does not compensate.

Procurement checklist

• Map the end-to-end production workflow and critical periods.
• Set measurable requirements before reading vendor wording.
• Mark every covered and excluded service component.
• Compare the contract definition with the status-page definition.
• Separate uptime, job success, performance and output quality.
• Confirm support hours and escalation by severity.
• Review historical evidence and one post-incident report.
• Document vendor dependencies and your fallback.
• Agree security-incident notification terms with privacy and security teams.
• Review service-credit mechanics and repeated-failure rights.
• Test export and recovery in the pilot.
• Put negotiated commitments in the signed agreement or incorporated schedule.

Use this alongside the broader trial-to-contract AI video procurement checklist.

FAQ

Is 99.9% uptime good enough for an AI video platform?

Not automatically. Suitability depends on scope, calculation, exclusions and the cost of disruption. A narrower but workflow-relevant commitment can be more useful than a high headline percentage.

What is the difference between an SLA and an SLO?

An SLO is a measurable service target. An SLA is the contractual arrangement that may include SLOs, responsibilities, measurement and remedies. Vendors sometimes use the terms loosely, so rely on definitions in the agreement.

Should generation speed be in the SLA?

Include a measurable objective if generation latency is business-critical and can be defined for a representative workload. Avoid a vague promise such as “fast rendering.”

Do service credits compensate for business loss?

Usually they are limited contractual remedies, often capped and applied to future fees. Legal counsel should review their effect and any limitation-of-liability or exclusive-remedy wording.

Can a status page replace contractual reporting?

No. It is useful operational evidence, but contractual notification should define incidents, recipients, timing and communication obligations relevant to your organisation.

---

References

1. enterprise AI video support models
2. trial-to-contract AI video procurement checklist
3. NCSC, Cloud security principles
4. NCSC, Principle 2: Asset protection and resilience
5. NCSC, Principle 5: Operational security
6. NIST SP 500-307, Cloud Computing Service Metrics Description
7. ICO, Contracts between controllers and processors
8. Talk to Knowlify