Configure the Mortem SDK by passing aDocumentation Index
Fetch the complete documentation index at: https://docs.mortemlabs.com/llms.txt
Use this file to discover all available pages before exploring further.
MortemConfig object to the Mortem constructor. Most options have sensible defaults so you only need to supply your API key and agent ID to get started. Use SessionOptions each time you call mortem.startSession() to describe the individual agent run.
MortemConfig
Pass these options when you instantiate the Mortem client. Options marked required must be present or the SDK disables itself silently.
Your agent API key, shown once during onboarding in the dashboard. If this value is an empty string the SDK disables itself and logs a warning through your configured logger.
Your agent’s unique identifier, copied from the dashboard. Defaults to
"unknown" when omitted. Mortem uses this to route traces to the correct agent in the dashboard and to match the verify token on first run.A one-time token that proves you control this agent. The dashboard generates it during onboarding. Include it on the first run so the wizard can confirm the connection, then remove it from your environment and code — it cannot be reused.
The token is sent with the first batch flush and never again. After the dashboard shows the agent as verified, delete
MORTEM_VERIFY_TOKEN from your .env file.The URL of the Mortem ingest service. The default points to the hosted service. Override this in local development to point at your local ingest instance.
Tags every trace with the Solana environment your agent is running against. Accepted values are
"devnet" and "mainnet". Traces appear in the dashboard filtered by environment, which helps you keep dev and production runs separate.Set to
false to disable the SDK without removing it from your code. Useful in CI pipelines or when you want to silence telemetry temporarily. When disabled, all SDK calls are no-ops and nothing is sent to ingest.How often (in milliseconds) the SDK automatically flushes its internal buffer to the ingest service. Lower values reduce the risk of losing events if the process exits unexpectedly. Higher values reduce network overhead.
The maximum size of the internal event buffer in bytes (default is 100 KB). When the buffer exceeds this limit, the SDK forces a flush before accepting more events. Increase this value if your traces contain large payloads.
An optional logger for SDK diagnostics. The object must expose a
warn(message: string, context?: Record<string, unknown>): void method. SDK errors are best-effort and never thrown into your agent runtime — they are routed to this logger instead.SessionOptions
Pass these options to mortem.startSession() for each agent run. A session maps to a single trace in the dashboard.
A human-readable description of what this agent run is attempting to do. This becomes the trace title in the dashboard and in shared autopsy links. Write it in plain language — it is the first thing you see when reviewing a failed run.
Labels you can use to filter and group traces in the dashboard. Add as many as you need. Common examples: strategy name, token pair, environment, run mode.
Override the auto-generated trace ID. Use this when you need to correlate a Mortem trace with an ID from another system (for example, a job ID from your scheduling infrastructure). The SDK generates a ULID by default.
Override the client-level
agentId for this session only. Useful when a single Mortem instance emits traces on behalf of multiple logical agents.Backfill a start time for the trace. Use this when you want the trace timeline to reflect when your agent actually started rather than when
startSession was called — for example, if you initialize Mortem after some startup work has already completed.Payload encryption
Set theMORTEM_MASTER_KEY environment variable to enable AES-256-GCM encryption for all event payloads before they leave your process. Generate a key with: