Usage report dictionary: every field a self-hosted install sends

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 for where it goes and how to read your own copy of it.

Also check: Data and telemetry, Connect, 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

Overview

Configuration

Deployment

Infrastructure

Operations

Ops Console

Langy

Usage report dictionary: every field a self-hosted install sends

Standard fields

Operational fields

Subscription fields

Optional fields

Never collected

​Standard fields

​Operational fields

​Subscription fields

​Optional fields

​Never collected

Standard fields

Operational fields

Subscription fields

Optional fields

Never collected