stdout and stderr. It is built to cut through noise quickly: a timeline to spot error clusters, drag-to-filter to zoom into a window, and collaboration features so you and your team (or the fal team) can share and debug the same log line. For how logging works under the hood β the different log scopes, what is captured, and how request-level logs are exposed β see Logging.
Timeline and Filtering
The logs viewer opens with a timeline histogram of log volume over time, making it easy to see when errors spiked or clustered. From there you can:- Drag to filter β select a region on the timeline to narrow all logs to that window, instead of typing exact timestamps.
- Filter by severity β switch out of live mode and filter to errors (or any minimum level) to focus only on what matters.
- Filter by identifier β narrow logs by runner ID, request ID, or version ID, or scope to a specific endpoint.
Investigating a Log Line
Click into any log entry for options that make debugging faster:- Show in context β when you are filtered to error-level logs, expand a single error to see the surrounding log lines and full traceback that led to it.
- Share link β copy a link that opens directly to that exact log line, at that point in time and with the same filter applied, so a teammate lands on precisely what you are looking at.
Collaborating and Exporting
Debugging production apps is often a team effort, so the Logs page makes it easy to move logs out of the dashboard:- Copy multiple lines β bulk-select log lines and copy them (as CSV) to paste into Slack for a teammate or into an agent for analysis.
- Export as CSV β export the full, filtered set of logs at once.
Related
- Logging β log scopes, what is captured, and request vs runner logs
- Runner Analytics β logs filtered to a single runner, alongside telemetry and cold start stages
- Log Drains β forward logs to external services (Datadog, Splunk, or any HTTP endpoint) in real time