BugShot
Discover, fix, capture, and report bugs in one shot
141 followers
Discover, fix, capture, and report bugs in one shot
141 followers
Catch a bug and file a complete report from Chrome's side panel. Captures, console/network logs, and environment attach automatically. Or tweak the CSS live and send the before/after side by side. AI drafts it for you. Free, no account, straight to your tracker.
BugShot
Hey Product Hunt 👋
I'm a product designer. My job is to notice when something is four pixels off — and then the hard part starts, because I have to describe it. I'd screenshot the bug, type "the spacing looks off here" into a ticket, and a developer would have to guess which property I meant. The rest of the report was clerical work: reproduce it, copy the URL and the browser version, dig through the console, paste it all into a tracker. By the time you're done you've forgotten what you were actually working on.
So I built BugShot, a Chrome side panel that collapses that into one pass:
• Pick an element and fix it live. Edit its CSS right on the page — through form fields or a real CSS editor with autocomplete and color swatches. Every change is tracked as a before → after table in the report, so the developer gets the diff, not my adjectives. It resolves var() chains too, so the report says --color-primary instead of rgb(79, 70, 229).
• Capture what you need. An element, a region, a screen recording, or the last 30 seconds of the tab. Annotate it before attaching.
• Logs come along for free. Console, network, and user actions are recorded while BugShot is running, including inside cross-origin iframes.
• File it where you already work. Jira, GitHub, Linear, Notion, GitLab, Asana, ClickUp — or share straight to a Slack channel or DM.
No sign-up, no account. Everything runs locally in the extension and posts directly to your tracker — your screenshots, logs and report text never touch a server of mine. The one exception is OAuth: platforms that require a client secret (Jira, GitHub, Notion, Asana, ClickUp, Slack) have their auth code exchanged through a small proxy that relays the token and stores nothing. Linear and GitLab use PKCE and skip it entirely.
I'd love to hear where it breaks for you — especially which tracker or workflow you'd want next. Happy to answer anything in the comments.
This is a great idea. I do have a couple questions. You mention CSS editing in realtime. Who is the target audience for this feature? Would they know the cascading impact of such a change? A higher level CSS change could break or alter other areas of the site. Also, does it work with minified or compiled CSS? If so how does the actual line number of the CSS update get communicated back to the developer? You mention the network traffic at the time of the bug is attached, this to me is the most interesting part. Is a HAR file being attached? Is it parsed with data analysis? In my world CSS is rarely the case but the underlying dependencies, APIs or libraries are. The HAR analysis could really help debug the issue. Great work, I like where this is going.
BugShot
@webdevmorgan
Thanks Scott, these are the right questions.
On the CSS side — BugShot's a reporting tool, not a deploy tool. Your edits only live in your own view, nothing touches the real stylesheet, so there's no cascade risk to the actual site. The dev just gets the before/after render plus the property delta (padding: 8px → 12px on this element), and decides how to land it. Same deal with minified/compiled: it reads computed styles off the live element's CSSOM, not source, so it won't pretend to hand you a line number in a bundle (which wouldn't mean anything anyway) — just the visual intent and the exact diff to map back yourself.
Network's the part I keep coming back to as well. It captures structured entries — method, status, timing, request/response headers and bodies (payloads capped at 3MB, sensitive fields like auth headers/tokens masked, binary bodies skipped) — right next to the console and action logs, cross-origin iframes included. It already does HAR 1.2 export, and there's error-level parsing on top: 4xx/5xx and failed/CORS-blocked requests get filtered into a summary and highlighted. What's not there yet is deeper analysis — correlating a failure to its root cause — and that's exactly where I want to take it, because like you said, dependency and API failures are where the real signal lives.
Sinhyeok — the redaction thread with Hakan and the OAuth-proxy answer to Gal are exactly the kind of detail that builds trust here. I'm coming at this from the other side of your usual user, though: WinBidIQ's customers are federal-contracting SMB owners, not developers, and when one of them hits a bug they don't know what a console log is — I get "it's broken" over email and have to reproduce it myself with no repro steps. Is there a lightweight capture flow a non-technical external user could trigger — a link they click, describe the issue in plain English, and it still grabs console/network/environment for me — or is BugShot built around the reporter already having the extension and knowing what they're looking at?
BugShot
@medal411
Med — straight answer: today it's the second one. BugShot is built around the reporter having the extension installed and doing the capture from their own side panel — there's no link-click flow a non-technical external user can trigger. No embeddable widget, no shareable capture link, no SDK — nothing external can talk to it at all, which is deliberate on the security side, but the flip side is it also can't reach into a page it wasn't opened on.
Which means for the WinBidIQ case you're describing — a federal-contracting SMB owner emailing "it's broken" with no repro — BugShot doesn't solve it yet. That person would have to install the extension and know to open it, which is exactly the knowledge you're saying they don't have.
But you've put your finger on the most interesting split in this whole thread. What you're describing is recorder-side capture — the reporter clicks a link, types the problem in plain English, and console/network/environment tag along without them ever knowing what any of it is. That's a different architecture from what BugShot is today: it flips the model from "you instrument your own session" to "you instrument your users' sessions." Which is arguably a different product — closer to support triage than a dev tool.
I don't want to fake a timeline on something that's a real pivot rather than a feature flag. But the question I'd actually want to answer is the minimum one: what's the least a click-a-link flow would have to grab to save you the reproduction step? Console + network + URL + browser, or does the environment matter more than that for your case? Happy to keep going here, or take it to email if it gets into WinBidIQ specifics.
the part that stands out is the privacy claim, not the css diffing. a lot of bug tools that say everything stays local quietly still route auth tokens through their own servers, so I like that you called out the OAuth proxy explicitly instead of hiding it. does that proxy log anything at all for debugging on your end, or is it truly stateless per request
BugShot
@galdayan
Fair question — and honestly, it's the one I'd ask too. "Everything stays local" often has an asterisk hidden somewhere around OAuth.
In our case, the proxy is stateless. It's open source, so you don't have to take my word for it:
https://github.com/SinhyeokKang/bugshot-2/blob/main/oauth-proxy/worker.ts
All it does is exchange the authorization code for an access token and immediately relay the response back. It doesn't persist tokens or request bodies, and nothing is logged for debugging. There's no storage attached to the Worker either (no KV, D1, R2, or database), so there's nowhere for anything to land.
Your screenshots, logs, and report text never go near the proxy in the first place—they're sent directly from the extension to your tracker.
After reading your comment, I also double-checked the Cloudflare side: Workers Logs, Traces, and Log Exports are all disabled for that Worker, and there's no Tail Worker attached. The only thing Cloudflare exposes is aggregate metrics like request count, error rate, and CPU time—no request content, tokens, or user identifiers.
There are a couple of extra guardrails too: the proxy only accepts requests from the registered extension and only for our own client IDs, so it can't be used as a generic token-exchange service. And providers that support PKCE (like Linear and GitLab) don't use the proxy at all.
If you spot anything in the code that contradicts this, please let me know. I'd genuinely appreciate it.
finally something that grabs console logs automatically because honestly copying those into jira tickets every single time is kind of my least favorite part of the job. the live css tweak diff idea is actually clever too
BugShot
@abangciv
Thank you — that's exactly the pain point I built BugShot to solve.
One thing you might like: BugShot captures console and network activity across every frame, including cross-origin iframes like Stripe or chat widgets. Those are often the hardest things to reproduce because the relevant errors aren't always in the frame you're inspecting.
Everything is collected while BugShot is running, so by the time you decide to report a bug, the logs are already there.
To keep the ticket itself readable, BugShot adds a short summary and attaches the full console, network, and action timeline as a single logs.html file that developers can open and filter locally.
The before/after CSS diff plus console/network evidence is the important bit. AI can draft the ticket, but the raw evidence needs to travel with it so the developer is not debugging a summary of a bug instead of the bug itself.
BugShot
@krekeltronics
That's exactly the line I tried not to cross.
The AI draft only writes the prose—the title and description. It's entirely optional, and it never touches the evidence. Skip it, and the report is exactly the same, just without the prose.
Style changes are captured as a before → after table of the actual CSS declarations, not a description of them. If a value came from a design token, you'll see --color-primary, not the rgb(79, 70, 229) it happened to resolve to. Developers get the value they'd otherwise have to go looking for.
The logs travel with the report as a self-contained logs.html: the full console, network activity, and user-action timeline—not a digest. The ticket itself only includes a one-line summary so it stays readable, while the raw data is one click away in the attachment. You can filter by origin, inspect request and response bodies, or export everything as HAR or JSON. Nothing gets summarized along the way.
So the AI drafts around the evidence, never in place of it. If it ever became the only thing in the ticket, the tool would be worse than the screenshot-and-a-sentence workflow it was built to replace.
Finally something that captures console and network logs without me messing with devtools first. Honestly the side-by-side CSS tweak is kind of genius, saved me a whole back-and-forth with the designer already.
BugShot
@hikmetcantekin
That's the exact loop I built it to kill — I'm a designer, and "the spacing looks off here" used to cost us another round every single time.
One thing that might save you another round: if a value comes from a design token, the diff reports --color-primary instead of the resolved rgb(79, 70, 229). The developer gets the token name they'd otherwise have to look up, so nobody has to guess where the value came from.
Edits stack across elements too, so if you tweak three different things, they all end up in a single before → after table.
Really glad it's already proving useful. If you run into anything that slows you down, I'd genuinely love to hear about it