![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: Jan 5, 2026
\nEach Tailscale agent in your distributed network streams its logs to a central log server (at log.tailscale.com). This includes real-time events for open and close events for every inter-machine connection (TCP or UDP) on your network.
Because every connection requires two endpoints, and both endpoints log every connection, it's possible to detect lost or tampered logs by comparing the double entries of each endpoint. You could also use IDS (intrusion detection system) rules to automatically detect suspicious activity on your network.
\nEach client logs information about its own operation and its attempts to contact other nodes. The data collected and how it is used are described in our privacy policy.
\nYou can access logs locally for nodes on some desktop platforms.
\nWindows macOS iOS / tvOS Android Linux
\nLogs are stored in C:\\ProgramData\\Tailscale (or, more generally $env:ALLUSERSPROFILE\\Tailscale).
Some logs are centrally collected by Tailscale for debugging. This is done with a custom-built, high-capacity, high-reliability, distributed logging system.
\nClient operational logs are only accessible locally on each node, but you could stream your system- and container-level logs to the same centralized data store for further analysis. Network flow logs are available from the admin console when enabled.
\nIf you block client logging, Tailscale may not be able to provide technical support.
\n\nThis is possible if you set the TS_NO_LOGS_NO_SUPPORT environment variable in %ProgramData%\\Tailscale\\tailscaled-env.txt:
TS_NO_LOGS_NO_SUPPORT=true\nTo track when you can instead use the --no-logs-no-support flag, follow our GitHub issue for making it easier to use environment variables.
The Kubernetes Operator's reconciliation logs are centrally collected for debugging. These logs describe steps the Kubernetes Operator has taken to bring the deployed state in-line with the desired state regarding Kubernetes resources.
\nRefer to our privacy policy to understand the data collected and how we use it.
\nYou can access logs locally using the kubectl logs command.
If you deployed the Kubernetes Operator with Helm, add the TS_NO_LOGS_NO_SUPPORT environment variable to the operatorConfig.extraEnv section:
operatorConfig:\r\n extraEnv:\r\n - name: TS_NO_LOGS_NO_SUPPORT\r\n value: \"true\"\nIf you deployed the Kubernetes Operator with static manifests, add the TS_NO_LOGS_NO_SUPPORT environment variable to the Kubernetes Operator's Deployment:
env:\r\n- name: TS_NO_LOGS_NO_SUPPORT\r\n value: \"true\"\nNetwork flow logsare available for the Premium and Enterprise plans.
\nNetwork flow logs are available to help you understand which devices are connecting to one another over time, that is, the flow of traffic across your tailnet.
\nThese logs strictly do not contain any information about client operations or contents of network traffic.
\nNetwork flow logs must be enabled.
\nFlow logs can be configured to stream to a security information and event management (SIEM) system.
\nConfiguration audit logs record actions that modify a tailnet's configuration, including the type of action, the actor, the target resource, and the time.
\nAll users who have access to the admin console can inspect configuration audit logs in the Logs page of the admin console, and can filter these logs to find specific events.
\nConfiguration audit logs are enabled by default for all tailnets, and are available for the most recent 90 days.
\nAudit logs can be configured to stream to a security information and event management (SIEM) system.
\nLocal SSH session logs are not supported as of version 1.48.0.
\nYou can use Tailscale SSH session recording to streaming recordings from the server device.
\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}