Find platform and workspace logs

Last published : Nov 09, 2026
Citrix SecurSpaces™ writes logs in four places: the management console, the Kubernetes logs of the platform services, the workspace pods, and an optional SIEM export. Start with the table below to find the log that answers your question, then follow the section for that log.
Related information
Operations

Which log to check

Symptom Log to check Where
A workspace failed to start or stopped with an error Workspace error logs Management console
A workspace starts slowly, or a startup script or repository clone failed Workspace startup log Management console
Errors in the management console or the API Debug and error reports, then the platform service logs Management console, Kubernetes
A problem inside a running workspace, such as Docker or the IDE Workspace pod logs Kubernetes
Who did what, and when Audit events Management console

Logs in the management console

These logs are stored in the SecurSpaces database, so they survive pod restarts. You do not need access to the cluster to read them.

Workspace error logs

The workspace error logs show why Kubernetes could not start or keep running a workspace, for example an image that could not be pulled, a container that ran out of memory, or a workspace that could not be placed on a node.
  • The log fills in while the workspace starts, so you can watch it as the start progresses.
  • It stays readable after the workspace has paused.
  • It is replaced the next time the workspace starts. Copy the content before you restart the workspace if you need to keep it.
To open it, select Details on a workspace in the Error state. The Workspace Error Logs dialog shows the log and, for common causes such as an unavailable image, a suggested next step.
The workspace owner can open the log, as can users who can manage the workspace, such as the project owner.

Workspace startup log

The startup log records each step of a workspace start with its elapsed time: scheduling, image pulls, startup scripts, IDE setup, and repository cloning. Open it from More Actions (...) > Logs on the Workspaces page. See Read the startup log.

Debug and error reports

Platform administrators and security officers can download two reports from Platform Settings > Analytics & Privacy > System Analytics:
Report Content Kept for
Debug analytics Log lines from the platform services, filtered by workspace, user, or time range 7 days
Platform crash analytics Failed API calls, grouped by error 30 days
See Analytics.

Audit events

Audit events record sign-ins, data security events, and administrative actions, and are kept for 360 days. See Audit and Audit events.

Platform service logs

Each platform service writes plain-text logs to standard error, which you read with kubectl logs. The services run in the namespace you installed SecurSpaces into, and their names start with the Helm release name.
Service Deployment
Central service <release>-central-service
Workspace API <release>-workspace-api
Proxy <release>-proxy
Coordinator <release>-coordinator
Frontend <release>-frontend
kubectl logs -n <namespace> deploy/<release>-central-service --since=1h
Kubernetes keeps these logs only as long as the container log rotation of your cluster allows, and a restarted pod loses most of its history. To keep them, collect them with your cluster's logging agent, as described in Keep logs for longer.

Turn on debug logging

The services log at the information level by default. To add debug lines and a line for each HTTP request, set the following in your Helm values and redeploy:
platform:
  isDeploymentDebugMode: true
Debug logging produces much more output. Turn it off again when you have the information you need.

Workspace pod logs

Each workspace runs as a pod in the same namespace as the platform. List the pods to find the one for the workspace:
kubectl get pods -n <namespace>
Container What it logs Command
ide-init-container IDE preparation before the workspace starts kubectl logs -n <namespace> <pod> -c ide-init-container
proxy-sidecar The workspace proxy, port forwarding, and the command server kubectl logs -n <namespace> <pod> -c proxy-sidecar
vs-code The browser IDE kubectl logs -n <namespace> <pod> -c vs-code
Some components write only to files inside the pod. Read them with kubectl exec:
File Content Container
/tmp/docker_daemon.log The Docker daemon inside the workspace proxy-sidecar
/tmp/x11vnc-<display>.log The graphical desktop session The workspace container
kubectl exec -n <namespace> <pod> -c proxy-sidecar -- cat /tmp/docker_daemon.log
Workspace pod logs and files in /tmp are lost when the workspace pauses or its pod restarts. Read them while the workspace is running.
To see what Kubernetes did with the pod, such as scheduling, volume attachment, and image pulls, list the events in the namespace:
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Keep logs for longer

  • Audit events: forward them to your SIEM. See SIEM integration. The SIEM integration covers audit events only, not the service or pod logs.
  • Platform service and workspace pod logs: collect the container logs with your cluster's logging agent, such as Fluent Bit or Google Cloud Logging.

What to send to Citrix Support

Include the following with a support request:
  • The SecurSpaces release version.
  • The workspace name and project, if a workspace is affected.
  • When the problem happened, with the time zone.
  • The content of the workspace error logs, if the workspace failed.
  • The debug analytics report for that time window.
  • The kubectl logs output for the affected service or workspace pod.