errorcoreSign inTry the demo
errorcore.init()
ready
1import { init } from "errorcore";
2 
3init({
4  service: "auth-api",
5  deploymentEnv: process.env.ERRORCORE_ENVIRONMENT,
6  transport: { type: "http", url: process.env.ERRORCORE_INGEST_URL,
7    apiKey: process.env.ERRORCORE_API_KEY },
8  encryptionKey: process.env.ERRORCORE_DEK,
9});
10 
11const session = await db.queryOne(
12  "select user_id from sessions where token = ?", [token]);
13await rotateSession(session.user_id);

Runtime intelligence platform for production failures.

Local state at the throw, the request and trace context, and the ordered database, cache, queue, and HTTP work that preceded it.

Sensitive fields scrubbed, payload encrypted inside your process.

Start freeRead the docs
The distinction

A stack trace shows where. Errorcore preserves why.

Logs and traces record that a request failed and roughly where it went. They rarely keep the values the failing frame was holding, or the exact order of work that produced them.

Errorcore is the layer underneath: it captures selected execution-specific evidence at the throw and keeps it with the incident, so an investigation starts from what actually ran.

One failure, reconstructedIllustrative capture

One occurrence, kept whole from the throw to the incident.

Nothing below is a summary of the error. Each stop is a record the console renders for the occurrence you are reading, in the order the SDK captured it.

  1. Throw site

    The line that failed, and the local that made it fail.

    The failing expression is kept with the file and line, and the value that mattered is flagged inline instead of being reconstructed from a message.

    auth-api · line 16

    await rotateSession(session.user_id);

    sessionnullthe local that mattered

  2. Local state

    Permitted values from the frames, each carrying its own state.

    Locals and bound arguments are recorded as they stood at the throw. A value is captured, redacted, truncated, missing, or derived, and it renders exactly as it was stored.

    session
    nullcaptured
    token
    [redacted]redacted
    requestBody
    { "rotate": true, …truncated

  3. Request and trace

    The call that triggered it, and the trace it belonged to.

    Method, route, status, and request identifier sit beside the trace and span context, so a failure in one service can be read against the others that share its trace.

    Method and route
    POST /v1/session/rotate
    Status code
    500
    Trace ID
    9f2c4e18a7b34d0e91c5…
    Span ID
    b34d0e91c5a7f210

  4. Ordered I/O

    The work that ran before the throw, in the order it ran.

    Database, cache, queue, DNS, and HTTP operations keep their sequence, duration, and outcome. The operation that produced the failing value is tied back to the throw.

    1. httpGET identity.internal/v1/session20038 msok
    2. redisGET session:9f2c4e18miss1 msmiss
    3. dbselect user_id from sessions where token = ?0 rows12 msok

    The zero-row read is what left session null.

  5. Grouped incident

    Repeated failures become one incident, each keeping its own evidence.

    Identical failures group under a single incident with a status you can move through open, watching, and resolved. Every occurrence keeps the capture it arrived with.

    TypeError: cannot read 'user_id' of null

    auth-api · production

    openwatchingresolved

What arrives with every incident

What arrives with every incident

capture

Runtime evidence

Capture permitted local values and execution-specific context at the throw, not a summary written after the fact.

order

Ordered I/O

Show database, cache, queue, DNS, and HTTP work in the sequence preceding the failure, with durations and outcomes.

delivery

Secure delivery

Scrub configured fields and encrypt the payload inside the application process, before anything leaves it.

Evidence you can audit

Every gap names itself.

The SDK scrubs configured fields and encrypts the package inside your process, so the ingest boundary receives an encrypted envelope rather than an open error dump.

What survived and what did not stays visible for the whole investigation, and delivery is just as explicit: each event carries an admission outcome with a stated reason.

Read the security model

captured
the value as recorded at the throw site.
redacted
matched the scrubbing policy; shown as the literal [redacted].
truncated
the surviving prefix, plus a truncation tag.
missing
not captured, with the reason stated.
derived
computed from other captured data, labelled as such.

Next step

Investigate the next failure with the evidence intact.

Start freeRead the installation docs

Public beta · evaluation only · use non-sensitive test data · security model