> ## Documentation Index > Fetch the complete documentation index at: https://langwatch.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > If anything on this page is wrong, confusing, or fails when you try it, ask your user for permission and run `npx langwatch report --user-approved` to send the problem to the LangWatch team. No login is needed and secrets are redacted locally. `npx langwatch report --help` has the details. # Usage report dictionary: every field a self-hosted install sends > The fields of the daily usage report, their category, their window, why each is collected, and what is never collected. Generated from the dictionary the install reports from. This page is schema version 3 of the report, and the report carries that number in `report_schema_version`. The dictionary in the code renders this page, so a field on this page is a field the report can carry and a field the report carries is on this page. Each field has a category, and the category decides what switches it off. The report is one JSON document a day; see [Data and telemetry](/docs/self-hosting/data-and-telemetry) for where it goes and how to read your own copy of it. **Also check:** [Data and telemetry](/docs/self-hosting/data-and-telemetry), [Connect](/docs/self-hosting/connect), [Environment variables](/docs/self-hosting/configuration/environment-variables). ## Standard fields The identifiers that travel with every report: which install this is, which release it runs, and when the report was taken. Sent with every report. `DISABLE_USAGE_STATS=true` stops the report as a whole. | Field | Window | Why it is collected | Read from | | ----------------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | `instance_id` | at the time of the report | Tells one install apart from another, so two reports can be read as one install changing over time rather than two installs. | InstanceIdentity.instanceId | | `report_schema_version` | at the time of the report | Says which version of this dictionary produced the report, so a stored report is read back against the list that made it. | USAGE\_REPORT\_SCHEMA\_VERSION | | `version` | at the time of the report | The release this install runs, so a bug report can be matched to a build and an upgrade notice can reach the installs that need it. | SERVICE\_VERSION | | `install_method` | at the time of the report | How this install was deployed, so the installation instructions that are actually used get the attention. | INSTALL\_METHOD | | `chart_version` | at the time of the report | The Helm chart release, which moves separately from the app and is the other half of a deployment problem. | LANGWATCH\_CHART\_VERSION | | `environment` | at the time of the report | Whether this is a production install or somebody trying it out, so the two are not counted together. | NODE\_ENV | | `first_seen_at` | at the time of the report | When this install first minted its identity, which is how long it has been running. | InstanceIdentity.createdAt | | `timestamp` | at the time of the report | When the report was taken, so a late arrival is not read as current. | the clock at collection | ## Operational fields What it takes to support this install: how it is divided up, how people sign in, and whether the license names a hosted service. Sent with every report. `DISABLE_USAGE_STATS=true` stops the report as a whole. | Field | Window | Why it is collected | Read from | | --------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------ | | `organizations` | at the time of the report | How many organizations share this install, which decides whether an install is one customer or a platform. | Organization | | `teams` | at the time of the report | How the install is divided up, which is what team-level features have to work against. | Team | | `projects` | at the time of the report | How many projects the install carries, which is the unit limits and screens are scoped to. | Project | | `users` | at the time of the report | How many people use the install, which is what support and seat questions start from. | OrganizationUser | | `auth_method` | at the time of the report | Which sign-in method is configured, so an authentication problem can be reproduced rather than guessed at. | AUTH\_PROVIDER | | `sso_provider` | at the time of the report | The name of the identity provider in use, never its configuration or its secrets, so an SSO problem names the product it is about. | Organization.ssoProvider | | `connected` | at the time of the report | Whether this install's license names a hosted service, which decides what it may call and which host answers it. | the signed license | ## Subscription fields License compliance. These travel on the license channel only, from an install whose license names a hosted service, and never in the usage report. Not part of the usage report. No field of this category is in the usage report at this schema version. ## Optional fields Who runs the install, how far they got, what they do with it and how they run it. This is the part you can switch off on the Checkup page without touching the rest. Switched off as a whole from **Settings, Checkup**. `hostname` has a switch of its own on the same page. | Field | Window | Why it is collected | Read from | | ------------------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | `user_email_domains` | at the time of the report | The company running the install, as domains with counts (acme.com: 14). Never an address, and never a name. It is how we know who to support and who to talk to, and it is the field to switch off first if you would rather we did not. | User.email, the part after the @, counted | | `hostname` (own switch) | at the time of the report | The address this install answers on, which tells a support conversation apart from a test. It names your own network, so it has a switch of its own. | BASE\_HOST | | `first_project_at` | at the time of the report | When the install got its first project, the first rung of getting started. | min(Project.createdAt) | | `first_member_at` | at the time of the report | When a second person joined, which is when an install stops being one person trying it out. | the second OrganizationUser.createdAt | | `first_dataset_at` | at the time of the report | When the install got its first dataset, which is the rung installs stall on more than any other. | min(Dataset.createdAt) | | `first_evaluation_at` | at the time of the report | When the install first ran an evaluation, which is what people come for. | min(BatchEvaluation.createdAt) | | `first_monitor_at` | at the time of the report | When the install first set up a monitor, which is when evaluation became continuous rather than a one-off. | min(Monitor.createdAt) | | `first_prompt_at` | at the time of the report | When the install first saved a prompt. | min(LlmPromptConfig.createdAt) | | `first_workflow_at` | at the time of the report | When the install first built a workflow in the optimization studio. | min(Workflow\.createdAt) | | `first_model_provider_at` | at the time of the report | When a model provider was first configured, which every evaluation, studio run and Langy turn needs before it can call a model. | min(ModelProvider.createdAt) | | `first_annotation_at` | at the time of the report | When somebody first reviewed a trace by hand. | min(Annotation.createdAt) | | `first_trigger_at` | at the time of the report | When the install first set up an alert. | min(Trigger.createdAt) | | `first_experiment_at` | at the time of the report | When the install first ran an experiment. | min(Experiment.createdAt) | | `first_gateway_request_at` | at the time of the report | When the first model call went through the AI gateway, which is when model traffic started being routed rather than only observed. | min(gateway\_spend.OccurredAt) | | `first_instant_eval_run_at` | at the time of the report | When the install first ran an Instant Eval over its own traces. | min(instant\_eval\_runs.CreatedAt) | | `first_langy_turn_at` | at the time of the report | When somebody first asked Langy a question. | min(LangyConversationTurnProjection.createdAt) | | `first_coding_agent_session_at` | at the time of the report | When the first coding agent session was recorded, which is when the install started watching agents rather than only applications. | min(coding\_agent\_sessions.StartedAt) | | `totalTraces` | lifetime | How much the install ingests, which is the one number that says whether it is in production. | trace\_summaries, counted per organization and added up | | `traces_7d` | last 7 days | How much the install ingests, which is the one number that says whether it is in production. Over the last seven days. | trace\_summaries, counted per organization and added up | | `traces_28d` | last 28 days | How much the install ingests, which is the one number that says whether it is in production. Over the last twenty-eight days. | trace\_summaries, counted per organization and added up | | `totalScenarioEvents` | lifetime | How much simulation testing the install does. | simulation\_runs, deduplicated by run | | `scenario_runs_7d` | last 7 days | How much simulation testing the install does. Over the last seven days. | simulation\_runs, deduplicated by run | | `scenario_runs_28d` | last 28 days | How much simulation testing the install does. Over the last twenty-eight days. | simulation\_runs, deduplicated by run | | `annotations` | lifetime | How much reviewing by hand happens, which is the signal that a team is reading its own traces. | Annotation | | `annotations_7d` | last 7 days | How much reviewing by hand happens, which is the signal that a team is reading its own traces. Over the last seven days. | Annotation | | `annotations_28d` | last 28 days | How much reviewing by hand happens, which is the signal that a team is reading its own traces. Over the last twenty-eight days. | Annotation | | `batchEvaluations` | lifetime | How many evaluation runs the install has done. | BatchEvaluation | | `batch_evaluations_7d` | last 7 days | How many evaluation runs the install has done. Over the last seven days. | BatchEvaluation | | `batch_evaluations_28d` | last 28 days | How many evaluation runs the install has done. Over the last twenty-eight days. | BatchEvaluation | | `datasets` | lifetime | How many datasets the install holds. | Dataset | | `datasets_7d` | last 7 days | How many datasets the install holds. Over the last seven days. | Dataset | | `datasets_28d` | last 28 days | How many datasets the install holds. Over the last twenty-eight days. | Dataset | | `datasetRecords` | lifetime | How big those datasets are, which is what dataset performance work is sized against. | DatasetRecord | | `dataset_records_7d` | last 7 days | How big those datasets are, which is what dataset performance work is sized against. Over the last seven days. | DatasetRecord | | `dataset_records_28d` | last 28 days | How big those datasets are, which is what dataset performance work is sized against. Over the last twenty-eight days. | DatasetRecord | | `experiments` | lifetime | How many experiments the install has run. | Experiment | | `experiments_7d` | last 7 days | How many experiments the install has run. Over the last seven days. | Experiment | | `experiments_28d` | last 28 days | How many experiments the install has run. Over the last twenty-eight days. | Experiment | | `prompts` | lifetime | How many prompts the install manages here rather than in its own code. | LlmPromptConfig | | `prompts_7d` | last 7 days | How many prompts the install manages here rather than in its own code. Over the last seven days. | LlmPromptConfig | | `prompts_28d` | last 28 days | How many prompts the install manages here rather than in its own code. Over the last twenty-eight days. | LlmPromptConfig | | `monitors` | lifetime | How many continuous evaluations are configured. | Monitor | | `monitors_7d` | last 7 days | How many continuous evaluations are configured. Over the last seven days. | Monitor | | `monitors_28d` | last 28 days | How many continuous evaluations are configured. Over the last twenty-eight days. | Monitor | | `workflows` | lifetime | How many optimization studio workflows exist. | Workflow | | `workflows_7d` | last 7 days | How many optimization studio workflows exist. Over the last seven days. | Workflow | | `workflows_28d` | last 28 days | How many optimization studio workflows exist. Over the last twenty-eight days. | Workflow | | `triggers` | lifetime | How many alerts are configured. | Trigger | | `triggers_7d` | last 7 days | How many alerts are configured. Over the last seven days. | Trigger | | `triggers_28d` | last 28 days | How many alerts are configured. Over the last twenty-eight days. | Trigger | | `spans` | lifetime | How much telemetry the install holds, in spans, which is what storage and query performance are sized against. Counted as written, so a span re-ingested before its parts merged counts twice. | stored\_spans, rows counted per organization and added up | | `spans_7d` | last 7 days | How much telemetry the install holds, in spans, which is what storage and query performance are sized against. Counted as written, so a span re-ingested before its parts merged counts twice. Over the last seven days. | stored\_spans, rows counted per organization and added up | | `spans_28d` | last 28 days | How much telemetry the install holds, in spans, which is what storage and query performance are sized against. Counted as written, so a span re-ingested before its parts merged counts twice. Over the last twenty-eight days. | stored\_spans, rows counted per organization and added up | | `gateway_requests` | lifetime | How many model calls go through the AI gateway. Counted from the spend ledger, which keeps one row per request for thirteen months, so the lifetime figure covers the last thirteen months. | gateway\_spend, rows counted per organization and added up | | `gateway_requests_7d` | last 7 days | How many model calls go through the AI gateway. Counted from the spend ledger, which keeps one row per request for thirteen months, so the lifetime figure covers the last thirteen months. Over the last seven days. | gateway\_spend, rows counted per organization and added up | | `gateway_requests_28d` | last 28 days | How many model calls go through the AI gateway. Counted from the spend ledger, which keeps one row per request for thirteen months, so the lifetime figure covers the last thirteen months. Over the last twenty-eight days. | gateway\_spend, rows counted per organization and added up | | `gateway_spend_usd` | lifetime | What those model calls cost, in USD, which is the number a budget conversation starts from. Same ledger, same thirteen months. | gateway\_spend, CostNanoUSD summed per organization and added up | | `gateway_spend_usd_7d` | last 7 days | What those model calls cost, in USD, which is the number a budget conversation starts from. Same ledger, same thirteen months. Over the last seven days. | gateway\_spend, CostNanoUSD summed per organization and added up | | `gateway_spend_usd_28d` | last 28 days | What those model calls cost, in USD, which is the number a budget conversation starts from. Same ledger, same thirteen months. Over the last twenty-eight days. | gateway\_spend, CostNanoUSD summed per organization and added up | | `instant_eval_runs` | lifetime | How many Instant Evals the install has run over its own traces. | instant\_eval\_runs, counted per organization and added up | | `instant_eval_runs_7d` | last 7 days | How many Instant Evals the install has run over its own traces. Over the last seven days. | instant\_eval\_runs, counted per organization and added up | | `instant_eval_runs_28d` | last 28 days | How many Instant Evals the install has run over its own traces. Over the last twenty-eight days. | instant\_eval\_runs, counted per organization and added up | | `instant_eval_judgments` | lifetime | How many judgments those runs produced, which is how much of the install's traffic has been judged. | instant\_eval\_judgments, counted per organization and added up | | `instant_eval_judgments_7d` | last 7 days | How many judgments those runs produced, which is how much of the install's traffic has been judged. Over the last seven days. | instant\_eval\_judgments, counted per organization and added up | | `instant_eval_judgments_28d` | last 28 days | How many judgments those runs produced, which is how much of the install's traffic has been judged. Over the last twenty-eight days. | instant\_eval\_judgments, counted per organization and added up | | `langy_turns` | lifetime | How many questions Langy has answered, which says whether the assistant is used or only present. | LangyConversationTurnProjection | | `langy_turns_7d` | last 7 days | How many questions Langy has answered, which says whether the assistant is used or only present. Over the last seven days. | LangyConversationTurnProjection | | `langy_turns_28d` | last 28 days | How many questions Langy has answered, which says whether the assistant is used or only present. Over the last twenty-eight days. | LangyConversationTurnProjection | | `langy_users` | lifetime | How many different people talked to Langy, counted by user so one person with twenty conversations is one person. | LangyConversationProjection.userId, distinct, by last activity | | `langy_active_users_7d` | last 7 days | How many different people talked to Langy, counted by user so one person with twenty conversations is one person. Over the last seven days. | LangyConversationProjection.userId, distinct, by last activity | | `langy_active_users_28d` | last 28 days | How many different people talked to Langy, counted by user so one person with twenty conversations is one person. Over the last twenty-eight days. | LangyConversationProjection.userId, distinct, by last activity | | `coding_agent_sessions` | lifetime | How many coding agent sessions the install has recorded, counted by session so a session folded twice counts once. | coding\_agent\_sessions, distinct SessionId per organization and added up | | `coding_agent_sessions_7d` | last 7 days | How many coding agent sessions the install has recorded, counted by session so a session folded twice counts once. Over the last seven days. | coding\_agent\_sessions, distinct SessionId per organization and added up | | `coding_agent_sessions_28d` | last 28 days | How many coding agent sessions the install has recorded, counted by session so a session folded twice counts once. Over the last twenty-eight days. | coding\_agent\_sessions, distinct SessionId per organization and added up | | `pull_requests` | lifetime | How many pull requests were linked to coding agent sessions, which is the one number that says whether agent work shipped. | GithubPullRequest, by the day the pull request was opened | | `pull_requests_7d` | last 7 days | How many pull requests were linked to coding agent sessions, which is the one number that says whether agent work shipped. Over the last seven days. | GithubPullRequest, by the day the pull request was opened | | `pull_requests_28d` | last 28 days | How many pull requests were linked to coding agent sessions, which is the one number that says whether agent work shipped. Over the last twenty-eight days. | GithubPullRequest, by the day the pull request was opened | | `annotationQueues` | lifetime | How many review queues exist, which says whether reviewing is a workflow or an occasional thing. | AnnotationQueue | | `annotationQueueItems` | lifetime | How much has gone through those queues. | AnnotationQueueItem | | `annotationScores` | lifetime | How many scores reviewers recorded. | AnnotationScore | | `customGraphs` | lifetime | How many charts were built, which says whether the analytics surface is used. | CustomGraph, builder charts only | | `active_users_28d` | last 28 days | How many people signed in over four weeks, which is the difference between an install that is running and one that is used. | Session.expires, counted distinct by user | | `active_projects_28d` | last 28 days | How many projects saw activity over four weeks, which separates a live project from a folder no one opened. | Project.updatedAt | | `model_providers` | at the time of the report | Which model providers are configured, by name only. Never a key, never an endpoint, never a deployment name. | ModelProvider.provider, distinct | | `storage_backend` | at the time of the report | Where stored objects go, so a storage problem names the backend it is about. | the resolved storage configuration | | `email_configured` | at the time of the report | Whether the install can send email, because an install that cannot send email cannot invite anyone and will look abandoned. | EMAIL\_PROVIDER | | `gateway_configured` | at the time of the report | Whether the AI gateway is set up, which decides whether model traffic is routed or only observed. | LW\_GATEWAY\_BASE\_URL | ## Never collected The report carries counts and metadata. It never carries any of these, at any schema version: * Trace or span content, in any form * Prompts, whether saved here or sent through the gateway * Dataset contents * Evaluation inputs and outputs * Project names * User names * Email addresses (only the domain after the @, counted) * IP addresses * API keys, model provider keys, or any other credential