Executions and usage
Every run is logged with its version, action reason, confidence and — if you allow it — input and output. Find executions, read usage and know how long logs are kept.
Executions
Every run — from the API or the Playground, successful or not — is recorded as an execution. Its ID is the execution_id of the response.
| Recorded | Notes |
|---|---|
| Decision and version | v3, or draft for Playground runs |
| Source | API or Playground |
| Status and error | Success or Error, with the error code and message |
| Action and action reason | for successful runs |
| Latency, model, input and output tokens, estimated cost | the model is the exact version that answered |
| Request ID | the X-Request-ID of the call — yours or the one Dcision generated |
Input (state) | only when the decision's storeInput is on |
| Output, confidence, weighted levels, composites, distributions | only when storeOutput is on |
| Destinations | the destination entries of the run — replies, LLM and agent answers, functions with their params, queued deliveries — whatever storeInput and storeOutput say |
Failed calls are recorded too — including invalid states (INVALID_STATE, token budget included) and engine errors — so you can see what your integration sends. A call answered with the engine-error fallback is recorded as an Error with the engine's code, although the API returned 200. Requests rejected before the decision runs — an invalid key or body, an unknown, disabled or undeployed decision, a rate limit, a quota block, an idempotent replay — are not recorded.
Find an execution
Executions lists the most recent runs first, 50 at a time (Load older for more). Filter by status, source and decision, or search by the beginning of an execution ID or by a decision name or slug. Selecting a run opens its details: action and reason, error, latency, model, estimated cost, request ID, input, output and the distribution of every question, its destinations with the live status of their deliveries — plus Re-run this input in the Playground.
Log the IDs
Store execution_id with the record your application acted on, and send your own X-Request-ID to correlate Dcision runs with your logs.
Read executions from code
GET /v1/executions lists the same runs with an API key — answers, action, reason, status, error code and metrics, filtered by decision and status, newest first. It never returns the input: stored states stay in the app, for workspace members.
Usage
Usage summarizes today, the last 7 days or the last 30 days:
- API calls and Playground runs;
- successful decisions and the error rate;
- average latency of all runs, and p50 and p95 latency of successful runs;
- estimated engine cost and input tokens;
- a volume chart — per hour for today, per day otherwise — with errors as a dashed line;
- a breakdown by decision: calls, errors, average latency, estimated cost and share.
The top card shows the billable decisions of the current billing period against your plan's included volume — also available from code with GET /v1/me. The Dashboard repeats the key numbers (decisions executed, p95 latency, success rate, estimated engine cost) with your live decisions, recent executions and the getting-started checklist.
Per decision: the Overview
Every decision's first tab, Overview, sums up its runs for 7, 30 or 90 days — success rate, latency, cost, actions and their reasons, per-question statistics, destinations — and suggests what to calibrate. See Overview and calibration.
Retention
A daily job deletes executions older than the shorter of your plan's retention and the workspace setting (Settings → Execution log retention):
| Plan | Log retention |
|---|---|
| Genesis | 7 days |
| Developer | 14 days |
| Growth | 30 days |
| Enterprise | 365 days |
For example, a Growth workspace set to 7 days keeps 7 days; a Genesis workspace set to 90 days keeps 7.
- Usage charts and tables are computed from executions, so they only cover runs that are still retained.
- Billing doesn't depend on logs. Billable decisions are counted separately, per hour, and those counters are kept for about 400 days: retention never gives quota back or changes what you pay.
- Deleting a decision deletes its executions immediately.
- Destination deliveries follow their own retention: they are deleted 30 days after they were created — see Delivery and retries.
Quota alerts
Workspace owners get an e-mail when the billable decisions of the period reach 80% and 100% of the included volume — once per level per period. See Plans, quotas and billing.
Playground
Test drafts — including unsaved edits — with real payloads, read confidence and distributions, preview destinations, compare runs and replay inputs from past executions.
Patterns overview
TypeSafe's four architectural patterns — speculative fan-out, confidence-gated routing, composite scoring and intent routing — and how each maps to Dcision features and templates.