Access Workspace Logs

Observability in Rocket.Chat helps administrators understand what is happening in a workspace by analyzing the data it generates. This data includes logs, metrics, and traces . They reflect how the workspace behaves under normal operation and during failures.

This document focuses on logs as the primary observability signal and explains how to access them, what changed in recent versions, and why adopting an external observability stack is recommended.

Why use an observability stack?

With the release of Rocket.Chat 8.0, the built-in Logs Viewer (previously located at Workspace > Reports > Logs) has been removed. Logging is now handled at the infrastructure level, and we recommend adopting a dedicated observability stack.

By using a dedicated observability stack, you gain:

Persistence: Logs survive container crashes, restarts, and updates.
Correlated debugging: Compare your Rocket.Chat logs side-by-side with MongoDB and Nginx events.
Advanced logic: Use query languages to find specific userIds or errorCodes across millions of lines instantly.

Configure log output

Logs provide detailed, time-ordered records of workspace activity. They are essential for investigating errors, diagnosing performance issues, and understanding unexpected behavior.

Workspace administrators can control what Rocket.Chat emits by configuring log settings under Manage Screenshot 2025-12-23 130522.png > Workspace > Settings > Logs. Refer to the Configure Workspace Logs guide for more details. While these settings control what Rocket.Chat emits, visualization is handled by your infrastructure or observability stack.

Access runtime logs

Rocket.Chat writes logs to standard output (stdout). How these logs are accessed, retained, and analyzed depends on your deployment model and infrastructure.

Docker

To check the status and logs of your Rocket.Chat container, follow these steps:

Use any of the following commands to list containers running in your Docker environment:

docker ps        # Shows currently running containers with details like ID, status, and ports  
docker ps -a     # Lists all containers, including stopped ones  
docker ps -q     # Displays only container IDs for a concise view  
docker compose ps  # Lists services managed by Docker Compose

Once you identify your Rocket.Chat container, you can inspect its logs using any of these commands:

docker compose logs -f <Service_Name>  # If using Docker Compose, this follows real-time logs  
docker logs <Container_Name>       # Displays logs for the specific Rocket.Chat container  
docker logs -f <Container_Name>    # Shows real-time logs (follow mode)  
docker logs --tail 10 <Container_Name> # Displays the last 10 lines of logs

Note:
Replace <Container_Name> and <Service_Name> with the appropriate values.
Rocket.Chat logs to stdout, so there isn't a specific log file within the container. The Docker logging system captures these stdout logs, making them accessible through the docker logs command

Kubernetes

To verify that the pods for your deployment are running:
```
kubectl get pods -n rocketchat
```
To view the logs for a specific Rocket.Chat pod:
```
kubectl logs -n rocketchat <pod-name>
```
To stream real-time logs from a running Rocket.Chat pod:
```
kubectl logs -n rocketchat -f <pod-name>
```
This helps in tracking ongoing events and debugging issues as they occur.

To check MongoDB replica set status:

kubectl exec -it mongodb-0 -n rocketchat -- \
  mongosh admin --eval "rs.status()"

Get the service details for the deployment:
```
kubectl get svc -n rocketchat
```