Every production error should end in a verified fix.
Open-source error tracking for coding agents.
Checkend hands each production error to your coding agent with a short brief. The agent claims it and ships a fix. Checkend closes the issue only when the error stops in production, and tells the agent if it comes back.
Hosted, or self-host on Cloudflare or Node/Docker · Any Sentry SDK · Apache-2.0
In early development: a public alpha (0.8.0). Server releases are signed.
Why
A fix is not done until production says so.
Error trackers were made for people who look at dashboards. The list grows, and someone clicks “resolve” to make the number go down.
Coding agents can now read a stack trace, find the cause and open a pull request. They need two more things: a clean description of the job, and proof that the fix worked. Checkend gives them both, and it keeps the issue open until the error stops in production, not until the pull request merges.
The issue brief
What an agent needs to start, in under 2,000 tokens.
The agent does not open a dashboard. It asks for the brief and gets only the useful parts: your frames, not the framework’s.
get_issue_brief(issue_id: 142) issue 142 TypeError: Cannot read properties of undefined (reading 'currency') first release 2026.10.2 suspect commit 9c41e0d "Allow carts without a price list" impact 312 events, 41 users affected frames app/checkout/total.ts:48 formatTotal 46 export function formatTotal(cart: Cart) { 47 const list = cart.priceList > 48 return money(cart.total, list.currency) 49 } app/checkout/summary.tsx:31 CheckoutSummary similar 88 (verified, similarity 0.91)
Sample data.
| Field | What the agent gets |
|---|---|
| Frames | In-app stack frames with the source lines around each one |
| First release | The release where the error first appeared |
| Suspect | A commit of that release that changed a file in the stack trace (a hint, not proof) |
| Impact | Events in the last 24 hours and 7 days, and the number of affected users |
| Similar | Issues with a similar meaning, when the optional similar-issue search is on |
| Trust | Whether the events came only from your servers, or also from browsers and apps, where anyone can send events |
Verified fixes
Resolved means the error stopped in production.
An agent links its fix, and CI reports deploys. Only Checkend can mark an issue verified, and only after a deploy with the fix is live and the error has stopped.
| State | Meaning |
|---|---|
unresolved | The error arrived and was grouped into an issue. An agent can claim it, so that other agents leave it alone, until the claim runs out. |
fix_pending | The agent linked a commit or a pull request. Checkend waits for a deploy that contains it, then for the quiet period. |
verified | A deploy contained the fix, and the error has stopped for the quiet period (24 hours by default). |
regressed | The error came back in a release with the fix. A webhook can start an agent with a new brief. |
Bring your SDK
Keep your Sentry SDK. Change one setting.
Checkend receives errors with the Sentry protocol, so any Sentry SDK can send to it. You do not touch your error-handling code. You point the SDK at your Checkend.
Sentry.init({ - dsn: "https://…@o4510.ingest.sentry.io/77", + dsn: "https://…@errors.example.com/4821937065", })
Tested with real requests from the Sentry SDKs for JavaScript (browser and Node), Python, Ruby, PHP, Go and .NET. Without a Sentry SDK, send JSON to one endpoint.
Grouping uses the error type and your in-app frames, and ignores line numbers. A deploy that moves code around does not split one issue into many.
Where it runs
Hosted, or on your own account.
Checkend Cloud runs Checkend for you, and updates it.
Or self-host it. On Cloudflare, Checkend is one Worker with a D1 database in your own account. Off Cloudflare, it is one Node process with one SQLite file, for example in Docker or on your server. Stack traces, request details and user IDs then stay in your account.
ce server install cloudflare, docker or ssh installs a signed server release, and ce server upgrade backs up, then upgrades. See Install with ce. The manual steps are in the docs too.
Agent interfaces
Built to be called, not watched.
| Interface | For |
|---|---|
| MCP server | Claude Code, Codex, Cursor and any other MCP client |
| CLI | ce, for scripts and agents. Every command prints JSON with --json. Install it with the install script, npm, Homebrew or go install (see Install ce). |
| HTTP API | Everything else. Described in an OpenAPI document. |
| Web view | People. A small view, for when you want to look. |
Open spec
Two documents any tool can adopt.
The format and the rules are published as drafts (v0.1), so other trackers and other agents can work the same way.
| Agent Issue Brief | The fields an agent needs to fix one error, and nothing more. |
|---|---|
| Fix-verification protocol | The states of a fix, and the rules that move an issue between them. |
Read the drafts in the repository: spec/.
Checkend is in early development.
It is a public alpha (0.8.0). Use Checkend Cloud, or self-host a signed release with ce server install, and watch the repository to follow the changes.