Launched this week
BugShot
Discover, fix, capture, and report bugs in one shot
135 followers
Discover, fix, capture, and report bugs in one shot
135 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.
honestly this looks super useful for my workflow but it would be great if you could save a default assignee or team channel per project so reports go straight to the right place without me having to select it every single time
BugShot
@peklrql
Thank you, İpek! This is really thoughtful feedback 🙏
Part of this already works today, although we clearly haven't made it obvious enough—that's on us.
BugShot remembers your last-used destination (repo, team, project, channel, assignee, labels, etc.) and pre-fills it the next time you report. You can also set defaults for each connected integration in the Connect tab.
That said, you're absolutely right about the missing piece: those defaults are currently stored per integration, not per project. So if you're working across multiple sites or repos, BugShot can end up defaulting to whatever you used most recently. That's a real usability gap, and I've added it to our roadmap.
One question, if you don't mind: would you rather have defaults tied to the website you're reporting from (e.g. staging.foo.com → repo X), or would a few named presets be more useful? I'd love to build whichever fits real workflows best.
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.
One thing I'd love is the ability to mark sensitive fields like emails or tokens for auto-redaction before the report gets sent. Even with a free tool, hitting send without scrubbing that stuff feels a little risky.
BugShot
@hakanzcpn
Funny timing — this is exactly what I worked on today.
BugShot already redacts sensitive data automatically, and the next release makes it even stricter. It detects common sensitive fields (passwords, auth tokens, etc.), masks values that look like email addresses or long numeric identifiers, and completely excludes content from rich-text editors like email composers and document editors.
That said, you're pointing at a real gap: today it's entirely heuristic-based. It catches most sensitive data automatically, but there will always be edge cases like internal IDs, customer references, or app-specific fields that don't look sensitive to a generic detector.
In the meantime, nothing gets sent blindly. Before submitting, you can open the log card to review exactly what was captured, or disable the action log entirely if you're working with sensitive data.
A user-defined redaction system is probably the right long-term solution, and it's already on my roadmap. I'm curious which you'd prefer: clicking a field on the page to always redact it, or defining rules or patterns once in settings that apply everywhere?