--- title: "The + Debug drawer: see what your page did, safely" section: "Builder Guide" canonical_url: "https://support.buildwithhq.com/builder-guide/debug-drawer.html" reviewed_at: "2026-09-14" authority: Official --- # The + Debug drawer: see what your page did, safely Open the built-in diagnostic timeline on any page to see what it did, what failed, and why — without exposing customer data. ## In brief - **Location:** Bottom of any page in an owned app - **Access:** Authorized builder - **Shows:** Safe outcomes, never raw data Every page in your app — in the builder console and in your live tenant application — carries a collapsed `+ Debug` control fixed to the bottom of the screen. Open it and you get an ordered timeline of the actions that page just took: navigation, form submits, database reads, and any AI calls it triggered, each with an outcome, a duration, and — when something failed — a safe reason and a way to follow it up. It's a diagnostic action timeline, not a browser console, packet inspector, SQL profiler, or unrestricted log viewer. ## Why it's there Most of the time a builder finds out something is wrong from a customer complaint, long after the failure happened and with none of the context that would explain it. The debug drawer closes that gap: it shows you, in the moment, exactly which step of the page failed, how long it took, and a correlation ID that ties it to the same event your team (or BuildWithHQ support) sees on the authoritative Logs side — so you can investigate immediately instead of waiting for a report to work its way back to you. ## Opening it Click `+ Debug` to open it. If the current page already has recorded failures, the collapsed control shows `Debug · N errors` without exposing any details until you open it. Opening the drawer starts a short-lived, server-issued session scoped to that exact page instance — it isn't a standing background logger, and it can't be extended indefinitely or resumed from another browser session. ## Reading the timeline Filter the timeline by **All**, **Errors**, **Network**, **Actions**, **Database**, **Workers** or **AI** — which filters are available depends on your role. Each row shows the UTC time, a safe operation name, its outcome, duration, the build/component version that handled it, and its correlation ID. A failed row adds a safe failure code and an **Open problem** action that takes you straight to the same event on the authoritative app Logs surface, at the same correlation, even if that means signing back in to the Builder Console first. For example, a page load might show a successful `page.definition.load` in 84 ms, followed by a `reservations.list` call that failed after 312 ms with the code `reservation_query_failed`, and then a retry that succeeded. That's usually enough on its own to tell you whether you're looking at a one-off blip or something worth investigating further — without reading a single line of a stack trace. Opening a row's expandable diagnostic section shows its sequence position, full occurrence time, event ID, action ID and parent action ID (or an explicit root-action label), so you or a teammate can follow the exact causal chain — which action triggered which — across retries and asynchronous follow-ups. ## Closing and reopening problems Once you've looked into a failure, close it from the drawer. Closing records who closed it and when, and the occurrence count at that moment — it does not delete or hide the underlying evidence. If the same failure happens again afterward, it reopens automatically with a higher occurrence count, so a recurring problem can't quietly stay marked closed while it keeps happening. Note Close, Resolve and Dismiss are lifecycle labels, not delete actions. Nothing in the drawer can erase recorded diagnostic history. ## What it deliberately never shows you The drawer is built to be safe to look at — and safe to hand to someone else. It never captures request or response bodies, exception or SQL text, stack locals, URL query strings, headers, cookies, tokens, AI prompts or model output, customer records, secrets, connection strings, or physical database/server names. What you see is limited to identifiers, safe operation and outcome codes, timestamps, durations, versions, and correlation — enough to investigate, never enough to leak a customer's data by accident. Important A marketplace publisher only ever sees causally linked events for their own exact published version — never your tenants' identities or content. A platform operator's view is similarly scoped and fully audited. Nobody outside your own app sees your data through this feature. ## Exporting for support Copy a correlation ID directly from any row, or export a sanitized diagnostic bundle for the whole session — the export shows exactly the same safe projection you can already see in the drawer, and every export is itself audited. That's usually all BuildWithHQ support needs to look at the same event on their side without you ever having to describe, screenshot, or paste anything sensitive. ## If Logs is temporarily unavailable A drawer diagnostic outage never changes what the page actually does for your customer — collection failure can only produce a bounded warning, never a different business outcome. If the Logs plane itself is briefly unavailable, the drawer shows an honest `diagnostics temporarily unavailable` state rather than pretending the timeline is simply empty. ## Session limits Debug sessions expire on their own and are capped on events, rate and size. When a session expires, the drawer keeps the history you already saw, stops capturing new detail, and offers **Start new session** — which closes the old session and starts a fresh one rather than reviving the expired one. Tip Closing the drawer only stops the extra successful-action detail it samples while open. Errors are always recorded through the normal failure-observation path, whether the drawer is open or not — you won't miss a real failure by working with it closed. ## Still expanding The drawer already covers page loads, their linked database reads, and AI calls like DataChat Ask across both the builder console and your live tenant pages. Deeper tracing into asynchronous worker and AI-job continuations, and dedicated marketplace-publisher and platform-operator views, are still being extended — so treat the drawer today as the fastest way to see what a page itself just did, with broader coverage arriving over time. --- Capability review: 2026-09-14. [View the canonical guide](https://support.buildwithhq.com/builder-guide/debug-drawer.html).