Service status
Hosted checks only. Local and BYOK work runs on your device and does not depend on our servers.
Checks passing
Last successful check: Mon, 19 Oct 2026 00:54:26 GMT (less than a minute ago)
11 hosted checks. Failing: none.
Seeing a fault this page does not show? Report a problem.
- ConfigurationPassing
Core service configuration is present in the serving environment. - PostgresPassing
A query is executed against the primary database and returns. The answer is reused for up to a minute. The first read after that starts another query and is itself answered with the older one, so this row is as old as the last successful check stated at the top of this page. - Cache storePassing
One read of a fixed key against the key-value store returns within a second. Rate limiting and cached reads fail closed without that store, so this counts as a core check. It does not exercise the rate limiter, and where no store is configured there is nothing to read, so the row passes and says not configured. - PaymentsPassing
A read call to the payments API returns and every plan price on sale is active. A failure here means some or all purchases may fail; existing plans keep working and chat is unaffected. - Chat routingPassing
The default managed chat route resolves to a live model, at least one provider behind it is configured, and the router has not marked every one of them degraded. It does not send a message through the model. - WorkPassing
The background job queues are draining: nothing has waited past the critical threshold and no worker lease has lapsed in bulk. This is the queue itself, not any one task. - Voice routingPassing
The default managed voice route resolves to a live model with a configured, non-degraded provider behind it. It does not open a voice session. - SearchPassing
The retrieval index the search over your own content reads is present in the database. It runs after the Postgres probe in the same run, so it is exactly as old as that row, and it never runs a query on your behalf. - Semantic searchPassing
The vector extension and the embedding index that semantic search over your own content reads are present in the database. The same catalogue query as the Search row answers it, and it never runs a query on your behalf. - Sign-inPassing
The identity provider answers with the signing keys every session is verified against, and a missed answer is asked once more before this row fails. A failure here means signing in and staying signed in may fail. It does not sign anyone in. - Account emailNot configured
A sender for account email is configured: scheduled task results, spend alerts and upgrade waitlist notices. Without one those still arrive in the app. It sends no message and does not check that one reaches an inbox.
How these checks work.
Every listed check passed on the most recent run. Model inference and a user chat turn were not tested.
A result is reused for up to 60 seconds and shared by everyone who loads this page inside that window. The next read after the window starts a new run in the background and is itself answered with the older result, so the first visit after a quiet period shows an earlier run. Every result is shown with its age, and it is marked stale once it is more than 120 seconds old.
The checked time is the moment the run actually happened, not the moment you asked. The page calls the health checks directly, in-process, rather than making an HTTP request to our own health endpoint. Building a request URL out of inbound headers is a server-side request forgery vector, so a status page that self-fetches is a status page with a security bug.
Sharing one run across visitors also keeps a traffic spike on this page from becoming load on the very dependencies it is reporting on. Same checks the monitored endpoint runs. Not a hand-edited badge. A passing result does not verify that a model returns a usable answer.
Where to read this when this page is down.
This page is served by the same deployment it reports on, so an outage broad enough to take the application down takes this page with it. Two fallbacks exist for that case, and both are last resorts rather than a second live feed. When an incident alert reaches nobody by email, pager or our own channel, it is retried on a transport that shares no vendor with our email, and the incident headline is written to an origin we do not serve. Neither runs while things are healthy, so the mirror carries the last incident rather than the current state, and both are silent unless configured in the serving environment.
- Status mirrorNot configured. This page is the only place status is published.
- If neither answersWrite to contact@agiworkforce.com. A reply may be delayed while the incident is open, but the mailbox is not hosted by this deployment.
What this signal proves, and what it does not.
A passing result is worth exactly 11 checks. Each row in the list at the top of this page states what it actually proves, which is narrower than its name. These checks cover the listed dependencies, not the entire platform.
- Model routesThe router tracks each model route separately and fails away from one that starts erroring, and operators read that per route behind their own sign-in. It is not published here, because the reading names which provider is failing and that is a third party outage to report, not ours. The Chat routing check is the public half of it: a provider fault fails that check only once every configured provider behind the default route is degraded.
- Not coveredA completed model response or answer quality · Object storage (Cloudflare R2) · The API gateway · The rate limiter (Redis) · Individual model providers and model routes · Desktop, mobile, extension, and CLI surfaces. A passing result says nothing about any of these. If one of them is failing for you, the report channel below is the fastest path.
Service levels, measured rather than declared.
Each row is computed from production rows over a rolling window, not from a hand-kept spreadsheet, and the objectives it is measured against are on /sla. When a domain burns its error budget fast enough to empty the month inside two days, the same numbers page whoever is on call. A window with no events says so rather than reporting a perfect score over nothing.
- AuthenticationNo samples in the last 30 days · objective 99.9%
- Chat95.56% of 180 events over 30 days · objective 99% · 0% of the error budget left
- First token98.26% of 172 events over 30 days · objective 95% · 65% of the error budget left · 95th percentile 2113ms
- Completion100.00% of 172 events over 30 days · objective 95% · 100% of the error budget left · 95th percentile 4462ms
- Tool executionNo samples in the last 30 days · objective 99%
- WorkNo samples in the last 30 days · objective 99%
- ResearchNo samples in the last 30 days · objective 95%
- File uploadNo samples in the last 30 days · objective 99%
- File parsingNo samples in the last 30 days · objective 99%
- SearchNo samples in the last 30 days · objective 99%
- Remote controlNo samples in the last 30 days · objective 95%
What each capability does when its dependency is gone.
Degrading is a decision made in advance, not whatever the last error path happens to produce. Work that has been accepted is held. A live action that cannot be held is refused at the door rather than queued against a page that has moved on, and a durable run that needs a device that is not online waits for it instead of failing.
- AuthenticationWithout the identity provider: A session already established keeps working until it expires. A new sign-in is refused rather than granted on an unverified token.
- ChatWithout the model provider serving the selected route: Auto rotates to another route for the same task. When every route in the plan refuses, the turn is failed rather than answered by a model the request excluded.
- WorkWithout the background job drain: Work is accepted onto its queue and held. Nothing is lost while the drain is down, and the run resumes from the queue when it returns.
- ResearchWithout web search and the model that reads its results: A run that loses search finishes on the sources it already gathered and the report says how many it reached, rather than presenting a partial sweep as a complete one.
- CodeWithout the sandbox that executes code: Code is still written and returned; it is not run. Nothing is presented as an execution result that was never executed.
- ToolsWithout the connector or MCP server behind the tool: The failing tool is reported to the model as failed and the turn continues without it. A tool that cannot run is never silently skipped.
- BrowserWithout the paired browser or the extension: A browser action is refused at admission rather than queued: a page has moved on by the time the pairing returns, so a held action would act on a page nobody is looking at.
Most of AGI runs without our servers.
The three trust modes have different failure domains. An incident on our side does not touch work that never leaves your device.
No dependency on AGI’s servers.
CLI Local sessions run on your own hardware through Ollama or LM Studio. They keep working during a hosted incident, including a full outage.
Traffic goes straight to your provider.
BYOK requests from the CLI travel directly to the provider you chose. The CLI and VS Code are coming soon. Desktop does not accept provider keys. If a model misbehaves, the provider’s own status page is the source of truth.
Public alpha, open by default.
Managed compute is in public alpha: signed-in users can use it now, with metered usage and visible provider labels. This is the only mode the signal above describes.
How we handle an incident, and what we owe you.
We have not published an incident archive or postmortems. Rather than leave that as an implied “no incidents ever”, here is the process and the commitment, so you can hold us to it.
- Severity 1Hosted platform cannot serve, or a confirmed unauthorised access to customer data. We start work immediately on discovery. The signal above shows the failing checks while we work; this page carries no written incident posts.
- Severity 2A major capability is unavailable or badly degraded for many users (for example managed chat, sign-in, or file upload) while the rest of the platform serves.
- Severity 3Degraded or partial function with a workaround, or an issue affecting a narrow set of users.
- NotificationFor a confirmed security incident involving customer personal data, we will notify affected account holders by email at the address on the account, and will do so without undue delay once we have confirmed scope. Where a data protection regulator requires notification, we will meet that obligation.
- On-callThere is no 24/7 rotation. Response is best-effort during working hours. This is stated plainly because assuming otherwise would be the dangerous reading.
- Security reportsA suspected vulnerability is not a status incident: it goes through coordinated disclosure, including our scope and safe-harbour terms, on /security.
Something looks wrong?
Release notes live in the changelog. Email an incident report with what you saw and when; the support page states the available channels and response commitments.