How to check logs of the web container?

[AdaChamberss]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

I requested a published workflow but got 404. The Dify nginx logs showed:

10.142.157.36 - - [21/Nov/2025:03:42:04 +0000] "GET /chat/XKtEZpHYfSjvf1Mx HTTP/1.0" 404 5708 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36" "10.142.81.41, 10.142.81.40"
10.142.157.36 - - [21/Nov/2025:03:42:04 +0000] "GET /console/api/system-features HTTP/1.0" 200 856 "http://10.142.157.36:8080/dify/chat/XKtEZpHYfSjvf1Mx" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36" "10.142.81.41, 10.142.81.40"

However the logs of the web container did not output new logs. So how to check the web logs to see what happened?

[dosubot[bot]]

To check the logs of the Dify web container (usually the api container in Docker deployments), you can use:

• docker compose logs api or docker-compose logs api
• docker logs <container_id_or_name> (replace with your actual container name or ID)
• To view the log file directly: docker compose exec api cat /app/logs/server.log

By default, logs are written to both stdout and (if configured) to /app/logs/server.log inside the container. You can customize the log file path by setting the LOG_FILE environment variable in your .env file. If you want to access logs directly from your host, mount the /app/logs directory as a Docker volume reference.

If you’re not seeing logs for 404 errors, check your log level settings (LOG_LEVEL in your environment or .env file). Detailed request/response logging only appears at DEBUG level and if ENABLE_REQUEST_LOGGING is enabled. Some 404s may not generate logs unless debug-level logging is active reference.

If logs are still missing, possible causes include frontend-backend communication issues, nginx misconfiguration, or API routing problems reference.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[AdaChamberss]

I want to see the logs of the 'web' container exactly. Its image is 'langgenius/dify-web'. I tink it's the frontend container. The 'api' container you mentioned is not what I want.
@dosu.

[dosubot[bot]]

To view the logs for the 'web' container (the frontend, image: langgenius/dify-web), use docker logs web or docker compose logs web. The container outputs all logs (startup, info, error) to stdout/stderr—there are no log files inside the container by default, and no log-specific environment variables to adjust this behavior.

If you’re not seeing logs for 404s or similar events, it’s likely because the frontend (Next.js) app only logs startup and server errors by default, not every HTTP error like a 404. For more detailed frontend logging, you’d need to add custom logging in the frontend code or use an error tracking service like Sentry via the SENTRY_DSN environment variable.

Reference:

• Dockerfile and entrypoint for web container
• Entrypoint script
• Server process and logging

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[AdaChamberss]

How to use an error tracking service like Sentry via the SENTRY_DSN environment variable?
@dosu.

[dosubot[bot]]

To enable Sentry error tracking in the Dify web (frontend) container, set the SENTRY_DSN environment variable with your Sentry DSN before starting the container. The entrypoint script will automatically export this as NEXT_PUBLIC_SENTRY_DSN for the Next.js app, and Sentry will be initialized in production mode if the DSN is set (entrypoint.sh, layout.tsx, sentry-initializer.tsx).

With Sentry enabled, the frontend will automatically capture unhandled errors, browser traces (performance monitoring), and session replays. By default, it samples 10% of traces and sessions, and 100% of sessions where an error occurs. 404s and handled errors are not sent unless you add custom Sentry capture logic in your frontend code.

You can also set NEXT_PUBLIC_SENTRY_DSN in your .env.local for local development, but Sentry only activates in production builds. For more, see the web/README.md in the repo (README.md).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}