Skip to main content

Application Logs

This page covers deployments running in your own Azure subscription (managed by us or by you). For an on-premises Docker install, see Application Logs (On-Premises).

Because the infrastructure runs in your subscription, you already have full access to every log line. Nothing extra needs to be installed, and there is no separate log CLI: you read the logs with the Azure tools you already have.

Where your logs live​

The application and its workflow workers write to standard output. Azure Container Apps ships that output to the Log Analytics workspace in your resource group, where it lands in the ContainerAppConsoleLogs_CL table. Application-level traces and metrics also flow to Application Insights in the same resource group.

Two extra sources are worth knowing about:

  • Azure Activity Log records every resource change, including each deployment. Use it to answer "what changed, and when".
  • Processing history per transaction is in the product itself, not in the platform logs. Open a transaction and look at its history to see which steps ran and how long they took. That is usually the faster place to start for a single failed document.

Reading the logs​

Live stream (Azure Portal)​

Open your resource group, select the DocAI Fabric container app, then Monitoring → Log stream. This tails the running replica, which is the quickest way to watch a document being processed.

Live stream (Azure CLI)​

az containerapp logs show \
  --name <your-container-app-name> \
  --resource-group <your-resource-group> \
  --follow

Querying history (Log Analytics)​

The Portal path is Log Analytics workspace → Logs, then run a KQL query. The last 100 errors:

ContainerAppConsoleLogs_CL
| where TimeGenerated > ago(24h)
| where Log_s contains "ERROR"
| order by TimeGenerated desc
| take 100

Everything logged around one transaction (paste its ID):

ContainerAppConsoleLogs_CL
| where TimeGenerated > ago(7d)
| where Log_s contains "<transaction-id>"
| order by TimeGenerated asc
| project TimeGenerated, Log_s

The same query from a terminal:

az monitor log-analytics query \
  --workspace <your-log-analytics-workspace-id> \
  --analytics-query "ContainerAppConsoleLogs_CL | where Log_s contains 'ERROR' | order by TimeGenerated desc | take 100"

Log Analytics is not instant: expect a delay of a minute or two before a new line becomes queryable. Use the live stream when you need to see something as it happens.

What to look for​

Every line is prefixed with a level (INFO, WARNING, ERROR). When you report an issue to us, the fastest thing to send is the last ERROR block plus the few lines above it, which usually name the transaction or the processing step that failed. You never need to share a whole log.

Retention​

Log Analytics is provisioned with the default retention of 30 days. Azure Activity Log is retained for 90 days at the subscription level automatically.

If you need longer retention for compliance reasons, options include:

  • Raising the Log Analytics retention to up to 730 days (incurs additional cost)
  • Configuring continuous export to a Storage Account for indefinite archival
  • Enabling the Log Analytics archive tier for low-cost long-term storage

Let us know your requirements and we can configure this when deploying or update it later.

Support Access to Logs​

Our support team reads your deployment's logs and metrics through Azure Lighthouse, read-only. For a deployment we operate, this access is required: it is how we detect, diagnose and fix problems without holding credentials or asking you to forward log excerpts. For a deployment you operate yourself, it is optional, and it lets us help much faster.

For deployments we operate, the Setup Guide covers it: what is granted, who registers it, and how to check it. The rest of this section is the reference for a deployment you operate yourself.

What Is Granted​

Microsoft's purpose-built mechanism for managed service providers. Our identities are projected into your resource scope without appearing in your Entra directory. The template below is exactly what gets registered, whether our pipeline or your team registers it.

How it works:

  • One registration authorises our Azure tenant with read-only access scoped to your DocAI Fabric resource group
  • We query logs from our own Azure Portal; no credentials are shared, nothing is stored on our side
  • Registering the authorisation is recorded in your Azure Activity Log
  • You can see and remove it at any time

The template. The authorisation template is published at:

https://app.docaifabric.com/docs/lighthouse/log-access-delegation.json

It is fully self-describing: it names our tenant, the single support group being authorised, and the three read-only role IDs, so your security team can review exactly what is granted before deploying. It contains no secrets and grants nothing by itself; it only takes effect when deployed by an Owner of your subscription.

When your team registers it, a user with Owner rights on your subscription (required for registering the delegation) runs:

az deployment sub create \
  --name docai-fabric-support-access \
  --location <YOUR_REGION> \
  --template-uri "https://app.docaifabric.com/docs/lighthouse/log-access-delegation.json" \
  --parameters rgName=<your-docai-resource-group>

If your policy requires deploying from a reviewed local copy, download the file first and pass --template-file log-access-delegation.json instead of --template-uri.

This grants our team Log Analytics Reader, Monitoring Reader, and Reader on your resource group only: no write access, no access to your documents, storage contents, or any other resources.

Removing access. You can remove the delegation at any time. For a deployment we operate, removing it stops us from supporting that deployment, so please talk to us first.

Security​

  • Read-only: we cannot modify, delete, or access any resources
  • Scoped to your DocAI Fabric resource group: no access to other resource groups, other workloads, or subscription-level resources
  • No access to documents: the roles cover logs, metrics and resource configuration, not the contents of your storage
  • No identities in your directory: our identities sign in to our own tenant, so no guest accounts are created and your guest sign-in policies are unaffected
  • Auditable: registering the access appears in your Azure Activity Log; if you want a record of our log queries too, Azure Monitor can audit queries