Status

Checking services…

Each component is being checked live. This takes a few seconds at most.

Components

Website
Operational
kensa.ai, the docs, and the download page.
Checked · Answered in 307 ms.
90 days ago100.00%Today
Derived · from the incident list above, while 250 recorded checks build up to a full day
Downloads & auto-update
Operational
The release feed installed copies of Kensa check for updates.
Checked · Answered in 300 ms.
Accounts & sign-in
Major outage
Creating an account, signing in, and refreshing a session.
Checked · Answered in 242 ms.
Backend API
Major outage
Team settings, shared learnings, and repository authorization.
Checked · Answered in 294 ms.
Desktop review runs
Operational
Reviews run on your machine against your own AI provider CLI. Kensa hosts no runner, so this depends on your provider, not on us.
Declared · Runs locally — no Kensa-hosted service sits in this path.

Services Kensa depends on

Claude (Anthropic)
Reviews run against the Claude CLI on your machine.
Their page says · All Systems Operational
Operational
OpenAI
Used when a review is configured to run on the Codex CLI.
Their page says · All Systems Operational
Operational
GitHub
Pull requests, diffs, and the release feed Kensa updates from.
Their page says · All Systems Operational
Operational
Cursor
Used when a review is configured to run on the Cursor Agent CLI.
Their page says · All Systems Operational
Operational

Active incidents

Sign-in and the backend API are unreachable

Ongoing · 29 d 10 h

Started 2026-09-06 23:59 UTC

accounts — Major outage
backend — Major outage

Investigating · 2026-09-07 00:10 UTC
Signing in fails and the backend API is not answering. The website and downloads are unaffected, and reviews already running on your machine are not affected either — they execute locally against your own provider CLI.
Identified · 2026-09-07 00:25 UTC
The TLS certificate on our backend host expired at 23:59:59 UTC on 6 September. Browsers and clients refuse the connection before any request reaches the service, which is why sign-in stops at a blank page. The certificate is issued and renewed by our backend provider, so the fix is theirs to apply; we are chasing it. Nothing is wrong with your account, and no data is affected.

How these numbers are produced

The status beside each component is a live check made when this page was rendered, from our servers, unless an incident above declares otherwise — a written incident always outranks an automated check. A component we do not probe is marked Declared, and a check that could not run reports Status unknown, never “operational”.

One limit worth stating plainly: the website row is partly circular. This page is served by the very deployment it reports on, so a total outage means the page is not served at all and can never be the thing that tells you. It does catch a broken route or a bad build while the platform is up. The rows that are checked — the backend, accounts and the release feed — are measured across the network and carry no such circularity. Desktop review runs is neither: it is declared, because nothing of ours sits in that path to measure.

Uptime is derived from the incident list on this page, not from a separate monitor: a major outage removes its full duration, a partial outage removes half of it (partial_outage = 0.5, major_outage = 1), and announced maintenance removes none. Days before we began keeping records are drawn as blanks and excluded from the percentage rather than counted as good days.

Record keeping began 2026-08-09. The same data is available as JSON at /api/status, which is what the desktop app reads.

Checking services…

Major outage in progress

Components

Website

Downloads & auto-update

Accounts & sign-in

Backend API

Desktop review runs

Services Kensa depends on

Active incidents

Sign-in and the backend API are unreachable

Scheduled maintenance

Incident history · last 90 days

How these numbers are produced