Send a crash, get a root cause back.

Install

Chronexis ships two official SDKs: Go and Python. If your service is neither, skip to the HTTP API below and call it directly — it's the same interface both SDKs wrap, so nothing is exclusive to either except the convenience layer on top.

SDK for Go

The Go SDK ships as the chronexis-go module (currently v0.2.2) and wraps automatic panic-recovery middleware around your existing handler.

go get github.com/Alraies97/chronexis-go

import chronexis "github.com/Alraies97/chronexis-go"

handler := chronexis.Middleware(
    "<YOUR_CHRONEXIS_API_KEY>", // find this on Settings after you sign up
    "https://chronexis.dedyn.io/v1/traces",
)(yourExistingHandler)

http.ListenAndServe(":8080", handler)

Any panic inside yourExistingHandler is now caught and reported. The request it happened on still fails with a 500, exactly as it did before — the middleware reports the panic, it doesn't swallow it.

Flush before your process exits

Reports are sent in the background, so a process that exits immediately loses whatever is still queued. Hold the service and flush it during shutdown.

service := chronexis.New(apiKey, ingestURL)
handler := chronexis.Middleware(apiKey, ingestURL)(yourExistingHandler)

// ... on SIGTERM, after srv.Shutdown(ctx):
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
service.Flush(ctx)

As of v0.2.1, Flush waits for reports to be actually delivered, not merely dequeued. It only waits on what was captured before the call, so it terminates even while your service is still handling traffic.

Background jobs and goroutines

Cron tasks, queue workers and goroutines have no incoming request for the middleware to wrap. Initialize once, then report errors directly.

chronexis.Init(apiKey, ingestURL) // once, at startup

func runJob() {
    if err := doWork(); err != nil {
        chronexis.CaptureError(err)
    }
}

CaptureError attaches the current stack trace itself. Called before Init or Middleware has run, it logs a warning locally and drops the report rather than panicking.

SDK for Python

The Python SDK isn't on PyPI yet — install it straight from the repo. Unlike the Go middleware, it doesn't hook into a web framework automatically: call capture_error yourself wherever you already catch exceptions.

pip install git+https://github.com/Alraies97/chronexis-python.git

from chronexis import Chronexis

sdk = Chronexis(
    api_key="<YOUR_CHRONEXIS_API_KEY>",  # find this on Settings after you sign up
    endpoint="https://chronexis.dedyn.io/v1/traces",
)

try:
    handle_request()
except Exception as exc:
    sdk.capture_error(str(exc), path=request.path, method=request.method)
    raise

capture_error only buffers — it returns immediately and a background thread does the sending. Shut the SDK down once, when your process is stopping:

sdk.close()  # flushes what's buffered, then stops the worker thread

Don't flush on the request path. flush() blocks until the buffer drains or its timeout expires — 5 seconds by default. Calling it in a per-request finally block makes every captured error stall that response for up to five seconds, which is the exact thing the background thread exists to avoid.

How delivery works

Both SDKs are built to sit in a live request path, which means the reporting call itself must never become the second incident. Capturing a crash never blocks your code — it appends to a bounded in-memory buffer and returns. Everything below happens on background workers.

A 429 is never retried in place — the request that just happened is precisely what the server asked us to stop doing, so retrying it would amplify the problem rather than recover from it. The Go SDK reads Retry-After as integer seconds, then as an HTTP-date (the form a fronting proxy emits), then as a retry_after field in the JSON body, falling back to 60 seconds — the length of the server's own rate-limit window. The two SDKs differ on what happens to the backlog: Go drops each report a worker picks up while paused, trading those reports for a guarantee it won't queue without bound; Python holds them and sends them when the pause lifts. Both reject an implausible Retry-After rather than clamping it — a server claiming "wait a week" is malfunctioning, not informing you — and both draw that line at 24 hours (max_retry_delay in Python), which is what a daily-quota 429 needs when it pauses you until UTC midnight. If nothing parses, both fall back to a 60-second pause, matching the minute window.

Tuning the Go defaults

What the Python SDK will not catch

The Python SDK installs no automatic capture path. It registers no WSGI or ASGI middleware and no sys.excepthook, so an exception your application doesn't wrap in its own except block is invisible to it. A hard kill — SIGKILL, an out-of-memory kill, os._exit() — also skips anything still buffered. The Go middleware genuinely is automatic for HTTP panics; Python is not, and we'd rather say so than have you find out during an incident.

HTTP API

Every route below takes your API key in an X-API-Key header. A trace that doesn't exist and a trace that belongs to someone else return the identical 404 — the response never confirms or denies which.

What a trace contains

The error and stack trace are kept exactly as sent — nothing sampled or summarized before the AI sees it. Once diagnosed, GET /trace/{id}/analysis adds six fields:

The three analysis states

GET /trace/{id}/analysis is always one of exactly three shapes — there's no fourth "something went wrong, try again" case to handle separately.

Rate limits

Standard, Pro and Max share the same ingest limits on purpose — those tiers differ by how many diagnoses you get and which model runs them, not by how fast you can send crashes. Exceeding either window returns 429 with a Retry-After; the official SDKs honor it for you (see how delivery works).

Full plan details, including diagnosis caps and pricing, are on the pricing section.