Measured response time
The probes behind the availability figure also record how long each component takes to answer. Those samples are published here, because "low latency" is not a claim until there is a number under it — and the number has to say what it measured.
Median response time · 2026-10-29T14:35:00Z to 2026-10-30T14:30:00Z
150 ms
- What is measured
- 19 monitored components across the EU production region only, 5472 probe samples taken every 300 seconds.
- Tail
- p95 300 ms · p99 396 ms. Nearest-rank over every sample, so each figure is an observed response, not an interpolation.
- Source
- The same public
status.jsonfeed behind the availability number. Anyone can read it back.
What this number is not
It is not document-processing time. The probes measure how fast an endpoint answers, not how long an extraction takes. Extraction time moves with document size and profile, and a 40-page PDF has nothing to do with the figure above. When we publish that number it will be measured separately and labelled as such.
It is not a contractual commitment. Like measured availability, this is history over a stated window. It changes every time we re-measure and it carries no service credits.
The slowest samples are kept, not trimmed. The probe cuts off at 10000 ms; 0 samples in this window reached it, so for those the true value is "at least that". Dropping them would flatter the tail.
| Service group | p50 | p95 | p99 |
|---|---|---|---|
| Internal Tools | 144 ms | 297 ms | 396 ms |
| Public API & Billing | 161 ms | 321 ms | 444 ms |
| Authentication | 162 ms | 324 ms | 402 ms |
| Content Management | 143 ms | 258 ms | 361 ms |
| E-Signature | 147 ms | 276 ms | 354 ms |
| Document Extraction | 153 ms | 296 ms | 402 ms |
| Workflow | 144 ms | 300 ms | 396 ms |
Region by region — US median not reported, EU median 150 ms. The figure above covers the EU production region only. A region reads not reported when its status feed carried no latency series for this window; it then contributes nothing to the figure, and the scope line above says so. Where both report, the gap between them is the network path from the probe to each estate as much as the estate itself, so read it as observed round-trip rather than one region being slower at its work. Each region's feed is generated independently and one can lag the other by a day, so each contributes its own most recent 24 hours.
Live status, per region
Cogneris runs separate production estates in the United States and the European Union. They fail independently, so they are reported independently. Each page shows current component state, a 24-hour response-time chart, a 90-day history strip, and incident records. A region whose status feed has stopped updating is paused: it is marked below, contributes nothing to the measured number, and its page keeps the last published history.
US production status
status-us.cogneris.aiState: paused; status feed last updated 2026-09-12. Over the window above: not measured across 0 components; lowest component not measured at not measured.
European UnionEU production status
status-eu.cogneris.aiState: measured; status feed last updated 2026-10-30. Over the window above: 99.7847% across 19 components; lowest component tickets-be at 98.5477%.
How the number is produced
Every claim on this page comes from the same feed the status pages render. The measurement is scripted, the output is committed, and a check fails the build if the page and the measurement disagree.
| Step | What happens |
|---|---|
| Collect | A collector polls each component through Cloud Monitoring uptime checks and writes a daily availability figure per component, per region. |
| Window | Complete UTC days from the first day on which every monitored component in both production regions had been in service for a full day. That rule exists because the raw 90-day history reaches back into the rollout, when components that were not deployed yet read as 0% and drag the fleet average to roughly 58%. Publishing that would be measuring the build-out, not the service. |
| Aggregate | The mean over component-days — every monitored component weighted equally on every complete day in the window. The worst single component is published alongside it, because an average on its own hides an outlier. |
| Publish | The result is committed to src/uptime-evidence.json and rendered here. CI re-checks
that this page, pricing, security, and the Trust Center all
render the committed figure. |
Window length — 86 days is short, and we would rather say so than stretch it. Every component in the EU production region only was in service on 2026-08-05; the window grows from there, and this page is re-measured as it does. Last measured 2026-10-29.
Incidents and notifications
Incidents are posted to the status page for the affected region as they are worked, with follow-up notes when the cause is understood. Customer notification obligations, response targets and the escalation path are contractual and set out in your agreement — see Security for how incidents are handled and Trust Center for the evidence package.
For environment endpoints and health checks, see environments.