Fixed release schedule
On by defaultPlatform releases go out on the first Tuesday of each month in the evening (CET). Extra releases are announced at least three working days ahead, and emergency hotfixes are released as soon as possible.
Reliability and SLA
Blits.ai commits to 99.5% monthly availability for cloud hosted deployments, measures it on a public status page and backs it with response and resolve times per priority. This is a summary of our standard Service Level Agreement.
Each capability is marked as on by default or configurable per assistant, workflow or tenant. Defaults that touch customer data can be switched off where regulation or your own policy requires it.
99.5%
Availability
Monthly availability target for cloud hosted deployments. Availability is scheduled uptime minus unscheduled downtime and emergency maintenance, divided by scheduled uptime. For on premises deployments, availability targets are agreed per contract.
Live status on status.blits.aiResponse and resolve times
95% of cases are responded to and resolved within these times.
| Priority | Enterprise | Pro and Pro+ | ||
|---|---|---|---|---|
| Response | Resolve | Response | Resolve | |
| P1 Critical | 1 hour | 4 hours | 1 hour | 20 hours |
| P2 High | 4 hours | 8 hours | 4 hours | 48 hours |
| P3 Medium | 1 business day | 5 business days | 1 business day | 5 business days |
| P4 Low | 2 business days | 2 weeks | 2 business days | 4 weeks |
P1 means production is down or so impaired that work cannot continue. P2 means critical features are unavailable without a workaround. P1 and P2 cases are worked on continuously until resolved, with status updates every hour for P1 and every four hours for P2.
How changes reach production
A fixed release rhythm, tests before every release and a fast way back.
Weekly content releases
On by defaultApproved content changes go live in the Thursday evening content release, within five working days of approval.
Tested before release
On by defaultBefore a release, the assistant is run against every affected question and each answer is checked against its expected answer. The customer receives the test report.
Guardrail tests every release
On by defaultEvery guardrail has its own test case, and all of them run before every release, so a guardrail keeps holding when content around it changes.
Version history
On by defaultEvery publish creates a numbered, unchangeable version of the whole assistant, with author, date, release note and a diff against the previous version.
Release gates
ConfigurableAn assistant can be set to reach production only when a selected test suite, including latency checks, passes on the new version. Overriding the gate needs an admin and a reason, and is logged.
Rollback in minutes
On by defaultProduction can point back to an earlier version in one click, without breaking live conversations. Every release is stored as a complete snapshot, so the previous state is restored within minutes while the cause is investigated.
Operations and monitoring
How we know the platform is healthy before a customer tells us.
Public status page
On by defaultAvailability is measured and published on status.blits.ai, and reported monthly to customers together with case statistics.
Health checks
On by defaultEvery service exposes liveness and readiness checks, including database connectivity, so failing instances are replaced automatically.
Latency checked after every deploy
On by defaultAfter each deployment an automated check compares live response times with a baseline, and the deployment is flagged when they regress.
Separate regional environments
On by defaultEach region runs as its own production environment, so an incident in one region does not affect customers in another.
Consistent answers
Language models vary by nature. These controls keep answers predictable where it matters.
Temperature per assistant
ConfigurableTemperature is set per assistant: 0.7 by default and adjustable, for example lower for factual answers. Guardrail checks run at 0.1.
Deterministic flows
ConfigurableJourneys that must always go the same way run as BPMN flows with fixed steps and exact wording, with intent recognition by Microsoft CLU, IBM, Google or Wit.
Regression test suites
ConfigurableMulti turn test sets graded by a model or by deterministic rules, run on demand or on a schedule from every 5 minutes to once a day, with alerts by email or webhook.
Reliability and SLA: FAQ
Want to see it on your own systems?
We run a working session on your use case, with your data and the models you choose.
Plan a call