Logging

Use handler logs to understand what your project did during a run. Sixb attaches the run and step context automatically, so you can inspect the output in Atlas.

Write a log

Handlers receive a logger. Add a message and structured fields where they help explain an operation:

// actions/mark-paid.ts
import { defineAction } from "@sixb/core"
import { Invoice } from "../ontology/invoice"

export const markPaid = defineAction("markPaid")
  .on(Invoice)
  .params({})
  .edits(({ subject, objects, logger }) => {
    logger.info("Marking invoice paid", { invoiceId: subject.primaryId })
    objects(Invoice).byId(subject.primaryId).update({ status: "paid" })
  })

Keep fields JSON-serializable and avoid logging credentials. Let failures propagate so Sixb can record the failed run.

View logs

Open Logs in Atlas to filter by run, kind, or level. Individual run pages also include their logs. Reading logs requires can.observe("logs") in a role.

Capture is enabled at info level by default. Stored logs have bounded retention; use an external output provider when you need longer retention.

To read logs in your own interface, use the Client SDK.

Configure output

Add an output provider to also send handler logs to your process output. Install @sixb/logger-pino, then add it to sixb.config.ts:

import { PinoLogger } from "@sixb/logger-pino"

const logger = new PinoLogger({ level: "info" })

Pass logger to createSixb(). See the Pino provider README for output options.

Capture settings are independent of the output provider. For example, pass this as observability to capture debug logs and redact a field:

const observability = {
  logs: {
    level: "debug" as const,
    redact: { paths: ["accessToken"] },
  },
}

Other capture options include enabled, maxLinesPerExecution, and retention. Field redaction here applies to captured logs; configure the output provider's redaction separately.

Report failures

Add onError to sixb.config.ts to report failures to your monitoring service:

import type { SixbErrorHandler } from "@sixb/core"
import { reportError } from "./lib/monitoring"

const onError: SixbErrorHandler = (error, context) => {
  reportError(error, {
    projectId: context.projectId,
    type: context.type,
    code: context.failure.code,
    notificationId: context.notificationId,
  })
}

Pass onError to createSixb(). reportError is your monitoring integration. Providing the callback replaces Sixb's default failure output to console.error.

Notifications may be repeated, and a process crash can prevent delivery. Use notificationId to deduplicate alerts. The callback does not change the operation's outcome.

See Errors for failure fields and stable error codes.