diff --git a/serverless/development/logs.mdx b/serverless/development/logs.mdx index c3bd3ab3..3d6a0a07 100644 --- a/serverless/development/logs.mdx +++ b/serverless/development/logs.mdx @@ -23,21 +23,47 @@ Endpoint logs are automatically collected from your worker instances and streame - **Standard output (stdout)** from your handler functions. - **Standard error (stderr)** from your applications. - **System messages** related to worker lifecycle events. -- **Framework logs** from the Runpod SDK. To learn more about the Runpod logging library, see the [Runpod SDK documentation](/serverless/workers/handler-functions). +- **Framework logs** from the Runpod SDK. -Logs are streamed in near real-time with only a few seconds of lag. +To view endpoint logs, navigate to your Serverless endpoint in the [Runpod console](https://console.runpod.io/serverless) and click the **Logs** tab. If your worker generates excessive output, logs may be throttled and dropped to prevent system overload. See [Log throttling](#log-throttling) for more information. -To view endpoint logs: +### Real-time streaming -1. Navigate to your Serverless endpoint in the [Runpod console](https://console.runpod.io/serverless). -2. Click on the **Logs** tab. -3. View real-time and historical logs. -4. Use the search and filtering capabilities to find specific log entries. -5. Download logs as text files for offline analysis. +The Logs tab streams new log entries automatically — no manual page refresh needed. Logs appear within a few seconds of being emitted by the worker. + +{ /* [CONFIRM: Is there a "Live" / "Pause" toggle in the UI? If so, document it here with the exact label.] */ } + +To scroll back through historical logs without the view jumping to new entries, scroll up in the log viewer. The stream continues in the background and new entries accumulate at the bottom. + +### Request filtering + +To view logs for a specific job, use the request filter: + +1. Click the **Filter** field at the top of the Logs tab. +2. Enter the job ID you want to inspect. +3. The log view updates to show only entries associated with that request. + +{ /* [CONFIRM: Is the filter field labeled "Filter", "Request ID", "Job ID", or something else? What does a user enter — the job ID from /run response, the worker ID, or something else?] */ } + +Filtering by request is useful when debugging a specific failed job in a high-traffic endpoint where logs from many requests are interleaved. + +To clear the filter and return to the full log stream, remove the value from the filter field. + +### View in context + +**View in context** lets you jump to the surrounding log lines for a specific entry. This is useful for seeing what happened immediately before and after an event of interest, such as an error or an unexpected output. + +To use View in context: + +1. Find the log entry you want to investigate. +2. Click **View in context** next to the entry. +3. The log view scrolls to and highlights that entry with the surrounding lines visible. + +{ /* [CONFIRM: Is the button labeled exactly "View in context"? Is it a button, a link, or a hover action? Does it appear on every log line or only on certain entry types?] */ } ## Worker logs