{"title":"Inspect your site using the web console","slug":"web-console","url":"https://support.storeconnect.com/articles/web-console","url_markdown":"https://support.storeconnect.com/articles/web-console.md","subtitle":null,"summary":"Debug your store in real time with the Web Console: trace Liquid template render chains, measure code execution with timer tags, and inspect payment and shipping API request and response logs.","type":"Help_Documentation","video_url":"","keywords":"web console, liquid template debugging, timer tag, request logs, api logs, payment debugging, shipping debugging, developer tools, template render chain, store debugging, code execution timing, browser console","last_modified":"2026-08-21T07:12:35+0000","body_markdown":"You can do the following via the web console:\n\n-   Analyze template output and logic\n-   Trace template render chains\n-   Detect and diagnose errors\n-   Identify opportunities for optimization and improvement\n\n## Enable user access \n\nWeb console access is only available to users assigned to an appropriate [Store Role](store-roles). Set these up first.\n\n## About the web console\n\nWhen you open the console, a new browser session starts and connects to a web socket in the background to receive logs. The console shows:\n\n-   **Connecting...** while establishing a connection.\n-   **Connected** once ready.\n\nAn **Open Store** button appears for convenience to launch the store in a new tab (optional).\n\nBrowse your store in the same browser profile. Logs for your requests will appear in the console for each page that you load.\n\n## Web console features\n\n### Request logs\n\n-   **Displayed** in the **sidebar** as you navigate.\n-   **Only your browsing activity** is logged, other customers’ activity is not visible.\n-   Logs are scoped to the **specific store** you launched the console from.\n-   Logs **do not persist** after closing or reloading the page.\n-   Sorted **most recent first**.\n-   **Controller** and **Action** (e.g., `products#show`) are displayed.\n-   Request **duration** is shown in milliseconds.\n-   **Red text**: indicates an error in the request.\n-   **Blue dot**: indicates a debug call was made.\n\n### Log details view\n\n-   Shows **request path**, **HTTP method** (GET, POST, etc.), and duration.\n-   Displays a nested view of **rendered Liquid templates**.\n-   Collapsible nested entries.\n-   Errors in collapsed entries show an error count\n-   Filter options: **All entries**, **Error entries**, or **Debug entries**.\n\n## Add a timer for a section of code\n\nYou can add a timer for a section of code to measure the code's execution time, and record the result in the web console.\n\n**Source:** `app/liquid/tags/timer_tag.rb`\n\n### Syntax\n\n\n```liquid\n\n{% timer \"label\" %}\n  {# liquid code to measure #}\n\n{% endtimer %}\n```\n\n\n### Parameters\n\n| Parameter | Type   | Required | Description                                         |\n|-----------|--------|----------|-----------------------------------------------------|\n| label     | String | Yes      | A name to identify this timer in the console output |\n\n### Example\n\n\n```liquid\n\n{% timer \"product-loop\" %}\n  {% for product in collection.products %}\n    {{ product.name }}\n  {% endfor %}\n{% endtimer %}\n```\n\n\nThe elapsed time for the block is recorded in milliseconds and appears in the web console under the given label.\n\n### Code timer rules\n\n-   Timers are only recorded during an active console session. The tag has no effect outside of a console context.\n-   Multiple timers can be used in the same template with different labels.\n-   Filter timings are also captured automatically for every filter invocation (with line number), without needing the timer tag.\n\n## Payment \u0026 shipping API responses and errors\n\n**Version 20.0.28** introduced **Payment and Shipping API logs** to the web console. These logs provide real-time visibility into APIrequests and responses for payment and shipping integrations, allowing developers to debug payment and shipping issues without needing access to external logging tools such as Papertrail, Heroku logs, or similar services.\n\n### What’s included\n\nWhen a payment or shipping API call is made, the web console displays:\n\n-   **Request details**\n\n    -   Endpoint\n    -   HTTP method\n    -   Payload sent to the provider\n-   **Response details**\n\n    -   Success or failure status\n    -   Response object returned by the provider\n    -   Error messages (when provided by the API)\n\nBoth successful and failed requests are logged and scoped to your current browsing session, consistent with existing web console behavior.\n\n### Common use cases\n\n-   Debug failed payments during checkout\n-   Verify successful payment or shipping rate requests\n-   Identify malformed payloads or missing parameters\n-   Review provider error responses without backend access.\n\n**Note:** Some payment or shipping providers may return limited error information. For example, certain APIs may respond with a `400` error without detailed context. However, most providers include meaningful error messages in their response bodies.\n\n### Example: successful payment API call\n\nIn the example below, a payment provider request completes successfully:\n\n-   A **REQUEST** entry shows the payload sent to the payment API\n-   A **RESPONSE** entry shows a `200` status with the provider’s response object\n-   The request is marked with a **blue dot**, indicating a debug call\n\n![Web console successful payment API call](https://res.cloudinary.com/hzkr6fi81/image/upload/v1767654765/knowledge/developer/Successful_Payment_API_Call_uv4exn.png)\n\n### Example: failed payment API call\n\nIn the example below, the payment API returns a failure:\n\n-   The response status is `400`\n-   The request entry is highlighted in **red**\n-   The request and response payloads are fully visible for debugging\n\n![Web console failed payment API call](https://res.cloudinary.com/hzkr6fi81/image/upload/v1767654764/knowledge/developer/Failed_Payment_API_Call_sgcg0o.png)"}