Why teams need Dify Enterprise invocation logs across workspaces
Platform owners need one place to review every app run across the organization, not one log per app. When Dify is used by several teams, each team builds apps in its own workspace, and failed runs, slow workflows and expensive model calls can sit in workspaces that no central administrator opens. The Community edition is limited to a single workspace, and the Dify pricing page places multiple workspaces and advanced administration in the self-hosted Enterprise edition. That is the reason organization-wide review belongs to the Enterprise administrator's work, not to each app owner's routine.
Per-app logs sit inside each app's own page and show runs for that app only. An app owner can use them to debug a workflow, but they do not give a platform team a cross-workspace view of status, duration, token use, or who triggered a run and from which source. Confirmed from the Dify docs: the app management documentation describes logs and monitoring at the app level, so treat that as the baseline. Still to verify in your Enterprise version: whether an organization-wide invocation view exists, which fields it records (status, duration, tokens, operator, source), how it filters failures, how long records are retained, and whether it can be exported. Ask the vendor for the Enterprise release notes and test these on a staging instance before you write any reporting process around them.
Before you rely on this view, decide who owns it, how often failures are reviewed, and which cost or latency thresholds trigger a follow-up with the workspace owner. Confirm with the vendor whether invocation records include the operator identity needed for accountability, and whether records from deleted or archived workspaces remain visible. If the organization needs longer retention or external analysis, plan a telemetry export separately, since that is a different pipeline from in-product review.
Which log view fits which review task
This table compares per-app logs, workspace-level review and organization-wide invocation review, with the questions each view answers and the details to confirm in your environment. Read each row by scope first, then match it to the question you need answered. The main takeaway is to start with the narrowest view that answers the question, and to confirm exact fields in your Dify version before writing review procedures around them.
| Log view | Scope and users | Typical question answered | What to confirm |
|---|---|---|---|
| Per-app logs | One app's log view. Used by the app builder and the app owner. | Why did this conversation or workflow run fail or return a poor answer? | Which fields (status, duration, tokens, source) appear in your version, and how long logs are kept. |
| Workspace-level review | All apps in one workspace. Used by workspace owners and platform leads for a team. | Which apps in this team's workspace produced the most failures this week? | Whether a workspace-wide run list exists in the Enterprise console, and which filters it offers. |
| Organization-wide invocation review | All workspaces, from the Enterprise admin console. Used by platform admins, security and audit staff. | Which workspace caused a spike in failures or token use across the organization? | Whether a cross-workspace run list is exposed, its fields, and whether results can be exported. |
| Failed-run triage | Filter applied within any view. Used by app owners and on-call operators. | Which runs ended in error, and at which workflow node did they stop? | The exact failure status values and whether node-level detail is shown in each view. |
| Token and duration analysis | Per-run metrics within a view. Used by cost owners and platform engineers. | Which app consumes the most tokens or runs the slowest over a period? | Whether token counts are stored per run in each view, or only available through telemetry export. |
| Operator and source attribution | Who or what triggered a run. Used by security and compliance reviewers. | Which member, service API key, web app visitor or external user triggered this run? | Whether each view records the operator and source type, and how external users are identified. |
Which fields to review in every run
Every app run in the organization carries the same core fields, and reviewing them together shows whether a problem sits in one app, one workspace or one caller. The cards below cover what each field tells an administrator and the pattern that should prompt a closer look. Confirm exact field names and availability in your Enterprise release before you build any report on them.
Run status
Status shows whether a run completed, failed or stopped early. Administrators check the failure share per app and per workspace, not just the total count, because a single broken node or expired credential often concentrates failures in one place. A sudden rise after a promotion or a model change points to a release problem rather than user behavior. Ask whether failed runs keep their error detail in the log view.
Run duration
Duration shows how long each run took from start to finish. Watch the trend for the same app over time, since rising duration with flat traffic often means slower retrieval, a slower model endpoint or a workflow branch that now loops more often. Compare durations across environments before blaming the platform. Confirm whether durations are recorded for node-level steps or only for the whole run.
Token usage
Token counts show how much model capacity each run consumed, which drives cost on most provider contracts. Look for spikes from a single source or a single app, such as a prompt that grew after an edit or a user loop that repeats long context. Token totals alone can mislead when runs use different models, so pair them with the model name where your release exposes it.
Operator identity
The operator field identifies the account or identity that triggered the run. Administrators use it to trace unexpected volume to a person, a service account or an automation, and to confirm that shared accounts are not hiding who acted. A run with no identifiable operator deserves attention, particularly for apps exposed through a web app or API. Check how SSO identities and API callers appear in the record.
Invocation source
The source field records how the run started, for example from the console, a web app, a service API or a scheduled trigger. Source separates internal testing from production traffic, which matters for cost allocation and for deciding which failures affect users. A new source appearing on a production app is a change to investigate, whether it was an integration added by a team or an unexpected caller.
Workspace and app identity
Workspace and app identifiers tie each run to the team and the application that owns it. Without them, organization-wide reports cannot assign cost, route incidents or confirm that a workspace is under its owner's control. Check that app names and IDs stay stable across environments, so staging and production runs can be compared. Confirm how renamed or archived apps and workspaces appear in historical records.
How to set up organization-wide invocation review
This sequence confirms licensing and roles, scopes which workspaces the reviewing team can see, proves that test runs appear correctly in the logs, and ends with a filter set and review routine that your team can repeat.
Confirm the Enterprise license and admin roles
Before anything else, confirm that your organization runs the self-hosted Enterprise edition rather than Community, since the Community edition is limited to a single workspace and the cross-workspace view depends on multi-workspace management. Ask your Dify administrator to confirm the license is active and identify which accounts hold workspace owner or admin roles and which hold the platform administrator role. Record each reviewer's account and role in your access register. This step is done when the administrator can sign in to the admin panel, see every workspace in the organization, and list the reviewers with their roles. Confirm the exact role names and their log permissions in your own version, because these vary between releases.
Map workspaces the review team can see
List every workspace in the organization and decide which ones the reviewing team needs to read. Include production workspaces, staging workspaces and any sandbox workspaces used by builders. Confirm with the Enterprise admin whether a reviewer's visibility is set by the workspace membership they hold or by a separate organization-level setting, and document the answer. Consider whether reviewers should see prompts and end-user inputs in full or only metadata, and check that your organization's data handling rules allow the chosen level of visibility. This step is done when you have a written table of workspace names, owners, the reviewers who can read each one, and the data each reviewer can see.
Run test invocations in a non-production workspace
Choose a non-production workspace and create or reuse a small set of test apps covering the app types your organization runs, such as a chat app, a workflow and an app that calls a knowledge base. Invoke each app with known inputs through the Dify interface and, if your teams call apps through the service API, through an API key as well. Use a separate test operator account for each invocation path so the operator and source fields can be checked against known values. Keep a written list of each test: app name, path, input, expected outcome. Include at least one run that is expected to fail, such as a call with a deliberately invalid model credential, so that failure filtering can be tested. This step is done when the test list is complete and every run has been executed once.
Check status, duration, tokens and source for each test
Open the organization-wide log view and find each test run from the previous step. For every run, compare the recorded status with the expected outcome, check that the duration is plausible for the input, confirm that the token counts appear and match what the model provider reports for that call, and verify that the operator and source fields identify the test account and the invocation path you used. Mark any field that is missing, blank or inconsistent. Where a token count does not match the provider's usage record, note the app, model and version so the difference can be traced later. Confirm with Dify's documentation how token and duration values are recorded for each app type, since workflows with several model calls may report them differently. This step is done when every test row has a pass or a documented discrepancy.
Check that the same runs appear per app and across workspaces
Open the per-app log for one test app and compare its entries with the organization-wide view for the same workspace. The two should show the same runs, statuses and token counts for that app. Then confirm that the organization-wide view also shows runs from a second workspace without you switching into it. Record any run that appears in one view but not the other. Differences usually point to a permission boundary, a filter left on by default, or a time zone setting, so resolve each one before you rely on the view. Ask your administrator to confirm whether logs for deleted apps or archived workspaces remain visible and for how long, because reviewers need to know whether historical runs are still available. This step is done when the two views agree for the test runs and the visibility rules are written down.
Define the filter set for failures and anomalies
Write a fixed set of filters that reviewers apply every time. At minimum, include status values that represent failure or error, a filter by workspace, a filter by app, a filter by operator or source, and a view sorted by duration so unusually slow runs are visible. Add a token-based filter if your version exposes one, and set a threshold you choose after reviewing a sample of normal traffic, since the researched facts do not supply a default value. Save the filters where your version allows, or write them as a shared procedure with the exact field names in your release. Test each filter against the failed run and the slow run from your test set. This step is done when each filter returns the expected test rows and nothing else.
Set the review routine and ownership
Assign a named owner for the review, a backup owner, and the workspaces each person covers. Agree on how often the filtered view is checked and how a failure is escalated to the workspace owner, the platform team and, where relevant, your security team. Write the routine as a short procedure that lists the filters to apply, the fields to record, and the evidence to keep, such as a dated export of the filtered view. Ask your administrator how exports are produced in your version and where they should be stored under your retention rules. Include a step to re-run the test set after each Dify upgrade, because log fields can change between releases. This step is done when the owner has run the routine once on the test data and has a dated record of the result.
How to filter for failures without drowning in noise
Start with failed runs only, then narrow in a fixed order: workspace, app, time window, and source. Filtering the organization-wide log by status first keeps the volume manageable, and the narrowing order matters because a spike in one workspace often traces back to one app, and that app's failures often cluster in a short window. Confirm with your Dify Enterprise version which filter controls the admin console exposes for status, workspace, app, time range and invocation source, and whether you can combine them. If a control you need is missing, plan to export the log and filter it outside the console instead of relying on memory or ad hoc queries.
Next, separate failures by cause before anyone opens a ticket. Errors caused by user input, such as malformed files or prompts that fail validation, usually belong to the workspace that owns the app and need guidance, not an engineering fix. Provider errors (rate limits, timeouts, expired keys), plugin errors and configuration errors (a missing variable, a credential assigned to the wrong workspace, a knowledge base that was moved) point to the platform team or the model owner. The log's error text and the run's node-level detail are where you make this call, so check them before classifying. Treat a classification as provisional until a second failed run confirms it.
Repeated failures from one source are the strongest signal in a noisy log. If the same app, credential, model or plugin produces failures across several runs or several users, group them and count them by window instead of reading each row. Then hand the finding to the workspace owner as a short record: the filter you used, the time window, the app and workspace, the failure count, the error text and one example run identifier, and whether you think the cause is user-side, provider-side, plugin-side or configuration. Ask the owner to confirm the app is still in use and whether any recent change, such as a prompt or model edit, preceded the failures. Keep the record in your own tracker so the same pattern is not reopened each week.
Security and privacy risks in run logs
Run logs record what users asked and what the model returned, so they often hold the same personal or confidential data as the apps themselves. The cards below cover where that exposure appears across workspaces: who can read run detail, what leaves the control plane in an export, and how long records live. Each card names a control to put in place and a question to put to the vendor before rollout.
Prompts and outputs carry sensitive data
Run detail includes the inputs users typed and the answers a workflow produced, which can contain customer identifiers, health or financial details, or internal strategy. Treat each run record as a copy of the source data, not as operational metadata. Map which apps handle regulated data, then decide which roles may open full run detail and which may see only status and duration. Ask the vendor whether run detail can be hidden from workspace-level roles while still showing failure counts to platform operators.
Role-limited access to run detail
Platform administrators who can see every workspace's logs can also see every workspace's data. Restrict organization-wide log views to a small named group, and give workspace owners access only to their own runs. Review who holds the admin role at least on the same cadence as your other privileged access reviews. Ask the vendor which roles can open run detail, whether that access is logged, and whether it can be scoped by workspace without giving a role access to other workspaces.
Exports carry the same risk
Once run records are exported to a file, a log platform, or a telemetry pipeline, they sit outside the Dify control plane and outside its access model. Apply the same encryption, access restrictions and retention limits to every destination, and record which fields leave the platform. Confirm with your security team whether exports include prompt and output text or only metadata such as status, duration and tokens. Ask the vendor which fields an export contains and whether text content can be excluded from it.
Retention must match policy
Run logs accumulate quickly in high-volume apps, and default retention may not match your records schedule or a legal hold. Set the retention period in writing before go-live, and confirm that it applies to every workspace, not only the default one. Deletion should remove run detail from the database and from any backups on a defined schedule. Ask the vendor how retention is configured, whether deletion is per workspace or per record, and how deleted runs are handled in backups taken earlier.
Backups hold the logs too
Database backups that include the metadata store contain every run record, including those already deleted from the live console. Protect backup storage with the same access and encryption controls as production, and align backup retention with the log retention policy. The SECRET_KEY setting also protects credentials stored in the platform, so keep it in a secrets store with restricted access. Confirm with your operations team how long backups are kept and who can restore them.
Log access is itself auditable
A log of who viewed or exported run detail is needed when an incident or access review asks who saw a given conversation. Check whether Dify Enterprise records viewing and export actions separately from the runs themselves, and where those audit events are sent. Plan to forward them to the same central logging platform used for other administrative actions. Ask the vendor for the exact list of events recorded and whether they can be exported with the run data.
How each role uses the invocation log view
Platform administrators bring the question of whether the organization's Dify estate is healthy as a whole: which workspaces produce failures, whether runs are slowing down and whether one team's activity affects others. They run the organization-wide review from the setup section each cycle and own the filters that span workspaces.
- Failure clusters by workspace: Filter to failed status across all workspaces, then group your reading by workspace to see where failures concentrate before opening individual runs.
- Duration outliers: Scan for apps whose runs take much longer than their peers, and note whether the slowdown follows a model, prompt or deployment change.
- Source patterns: Compare runs by source to confirm whether traffic comes from the console, the API or a web app, so you know which access path to investigate.
- Unfamiliar operators: Look for operators you do not expect on production-facing apps and pass those to the security reviewers.
Do not change workspace settings, app configuration or model credentials during a log review. Route those changes through the owners named in the setup section. Hand workspace owners a list of failing apps with timestamps, status and duration, and open infrastructure tickets only when the app itself does not explain the failures. Check that the review covered every workspace in the period, not only the ones you looked at last time.
Security and compliance reviewers bring the question of who ran which app, from where, and whether each run completed as designed. They need records that show usage matched approved access, and they need those records in a form they can date, repeat and hand to an auditor.
- Operator attribution: Confirm that each operator on sensitive apps maps to a known identity from your SSO setup, and flag any operator that does not.
- Source review: Check that runs from API or external sources come from integrations your team has approved.
- Failed and repeated runs: Review failures for patterns such as repeated attempts from one operator or source, which may indicate probing or misconfigured access.
- Retention and export: Ask your administrators how long invocation records are kept and whether they can be exported into your evidence file. Confirm these details in your own environment instead of assuming them.
Do not delete, edit or tidy invocation records to make a review cleaner, and do not change access settings yourself while collecting evidence. Hand the platform team specific operators or sources to investigate, and give the auditor a dated record of the filters, date range and findings. DeployOpen prepares systems and evidence for assessments, but independent auditors issue the assessment outcome. Record the filter settings used each cycle so the review can be repeated exactly.
Cost owners bring the question of which apps and workspaces consume tokens, and whether that consumption matches the budget each team was given. The invocation log shows token counts per run, but it does not show prices, so cost owners pair the log with rates from their model provider contracts.
- Token totals by workspace: Sum tokens per workspace for the period to see which teams drive usage and how that compares with their allocation.
- High-token runs: Find individual runs with unusually high token counts and check whether a prompt, workflow or retrieval change caused the increase.
- Failed runs that still consumed tokens: Check whether failures spend tokens, since retries after failures can multiply usage without producing output.
- Rate mapping: Ask your provider contract owner for the rate basis for each model in use, and apply those rates to exported totals in your own finance tooling.
Do not change model selection, budgets or workspace credentials on your own authority. Those decisions belong to the platform team and the workspace owners. Hand workspace owners a summary with token totals and the top apps by usage, and hand finance the rate basis you used so the figures can be checked. Confirm whether your license or model contracts set any cost limits, since the invocation log records usage but does not enforce spending.
Workspace owners bring the question of whether their apps work for their users, and what went wrong on the last failed run. Their review is narrower than the platform view, and it should stay within the workspaces they are authorized to see.
- Own-workspace failures: Filter to failed runs for each app and read status alongside duration, so you can tell a fast error from a slow timeout.
- Changes after edits: Compare runs before and after a version change to see whether a prompt, node or model edit altered behavior or speed.
- Operator questions: Check which team members run an app so you know who can reproduce a problem and who should be contacted about it.
- Source checks: Confirm whether a failing pattern comes from one source, such as an API integration or an embedded web app, rather than from the app itself.
Do not change apps in other workspaces, share logs outside your workspace or edit a production app in a way that hides failures from the record. Hand platform administrators the app name, the time window, the status and a sample failed run's timestamp. Hand security reviewers any operator you cannot identify. Confirm with your platform administrator which access level your role has in your version, because that determines which logs you can see.
Limits to confirm before you rely on these logs
Invocation logs answer operational questions only as far as their retention, content, token accounting and access model allow. Each card below is a question to put to the vendor or test in a pilot before finance, security or audit teams depend on the figures.
How long are run records kept?
Confirm the retention period for run records in Dify Enterprise, whether it is fixed or configurable, and whether it applies to failed runs as well as successful ones. Ask what happens to records older than the window, whether they can be exported before deletion, and who can change the setting. If your review cycle or incident investigations run longer than the retention period, plan an export pipeline before go-live.
Is prompt and output content stored?
Determine whether each log entry stores the user input, prompt text, model output and intermediate node values, or only metadata such as status and duration. Content capture decides both usefulness for debugging and the sensitivity of the log store itself. Ask whether content can be masked or disabled per workspace, and how access to stored content is restricted.
How are token counts produced?
Ask how token counts are calculated for each model provider, whether the figure comes from the provider's response or from a local tokenizer estimate, and how cached, reasoning or tool-call tokens are counted. Self-hosted models and plugin-based providers may report usage differently from cloud APIs. Run the same prompt against two providers in a pilot and compare the totals against your provider invoices before using them for chargeback.
What format do exports take?
Confirm whether logs can be exported, in which formats (for example CSV, JSON or a streamed event feed), how timestamps and time zones are written, and whether field names stay stable across releases. Ask whether the export includes the operator, source and error fields needed for filtering, and whether pagination or row limits could silently truncate a large extract.
Do logs cover API and scheduled runs?
Check whether runs started through service API keys, embedded web apps, and scheduled or trigger-based executions appear in the same log, and whether each carries a source identifier that separates them. Missing sources produce undercounted usage and gaps in failure analysis. Test one run from each entry point during the pilot and confirm the record matches what the app reported to the caller.
Who can see across workspaces?
Confirm which roles can open a cross-workspace view, whether a workspace owner sees only their own runs, and whether the view is limited by SSO group or role assignments. Cross-workspace visibility exposes prompts and operator identities from other teams, so ask whether it can be audited and whether access to the view itself is logged.
Common questions about Dify Enterprise invocation logs
What drives the cost of reviewing invocation logs across workspaces?
The main drivers are the number of workspaces, the number of apps in each, how many people need to see logs, and what reporting you need on top of the console. A single team with a few apps is a small review. Dozens of workspaces with different owners, a role model that limits who sees which runs, and a requirement to export records to your own reporting store add design and testing work. Cost is one-time for the design, log field mapping and test plan, and recurs only if you retain a support or review arrangement. Ask any partner for a written scope listing workspaces, apps, roles, export targets and the verification steps, since a fixed-scope quote follows from that document.
How long does setup take, and why does it depend on scope?
Duration depends on scope rather than on a fixed number of days. The work moves through confirming which log fields your Enterprise version exposes, defining filters for failures, duration and token use, setting access by workspace, and testing with real runs from each team. Each additional workspace owner to coordinate, each app with an unusual workflow, and each external reporting destination extends the schedule. Ask for a timeline in the written scope, along with the assumptions behind it, and confirm that the agreed milestones match your change approval calendar.
What must our team provide before an engagement starts?
You will need an administrator account with access to the Enterprise admin panel, a named contact for each workspace owner, and a test plan that lists the app runs to exercise, including successful runs, failures, slow runs and runs from each source such as the web app, API or debugging. Access to a staging environment helps, because test runs in production create real records and may use paid model calls. Your security team should also confirm where log data may be stored and who may read it before any export is configured.
Can our internal team review invocation logs on its own?
Yes, many teams do. The console already shows run records for apps, and an internal engineer who understands your workspace model can build filters and a review routine. The points that usually need outside help are consistent field mapping across versions, access rules that match your identity groups, and a repeatable export to a store your auditors or operations team can query. Decide which parts you own and which you want reviewed, and write that split down before work begins.
How do invocation logs differ from telemetry export?
Invocation logs are a per-run record in the Dify console that lets you review status, duration, token counts, operator and source across workspaces. Telemetry export is a separate pipeline that streams metrics and traces to your own OpenTelemetry collector for cost allocation and service level tracking. Telemetry is built for dashboards and alerts over time, while invocation logs answer questions about specific runs. Many organizations use both, and they need separate owners, retention settings and access rules. Confirm the exact fields and retention for your Enterprise version with the vendor before you design either pipeline.
Can DeployOpen confirm which log fields our Dify Enterprise version provides?
DeployOpen can plan the verification and run it in your environment, but it cannot promise a field list from the outside. We check the fields your installed version exposes by testing real runs from each source, recording what appears in the console and any export, and documenting gaps. Ask for the verification steps and the evidence format in the written scope. Fields that the vendor does not expose will be listed as gaps, and you can decide whether to accept them or change the design. Compliance evidence produced this way is supporting material for your own auditors, not an audit result.
How DeployOpen works on this
DeployOpen plans, implements and documents self-hosted Dify inside your own infrastructure, including how invocation logs from every workspace are collected, filtered and reviewed. We agree the log scope, retention and reviewer access in writing before work starts, then build and test the review path against your own deployment.
How we scope
- Engagements are fixed-scope, with the log fields, workspaces and review questions agreed in writing before work starts.
- We confirm which Dify Enterprise workspaces and environments are in scope, and which teams will read the organization-wide logs.
- We ask you to confirm retention periods, data classification and who may see prompts, outputs and operator identities in logs.
How we build
- We configure and test the failure, duration and token filters against sample runs in a non-production environment first.
- We check that operator and source fields match your identity setup, including how SSO-authenticated users appear in run records.
- We confirm where logs are stored and how they are reached, and document any gap between organization-wide and per-app views.
How we hand over
- You receive written documentation of the filters, saved views, field definitions and the review steps your team should follow.
- We walk your operators through a sample investigation of a failed run, from first alert to the workspace and app involved.
- We record open questions, such as fields your Dify version does not expose, so your team can confirm them with the vendor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so log reviews keep working across Dify releases.
- We can re-check log fields and filters after each planned upgrade, since minor releases arrive roughly monthly.
- Retainer work can include reviewing log access rights as workspaces are added, moved or archived in your organization.
