How we used Sentry’s User Feedback widget to shape Logs throughout beta

At Sentry, we build in public and we move fast. But moving fast means we don’t always get everything right on the first try. That’s where feedback comes in: it helps us validate what’s working, spot what’s missing, and catch issues we wouldn’t always see through error tracking alone.

When we launched the Logs beta a few months back (BTW, it just went GA last week, check it out), we wanted a way to catch what wasn’t obvious with our error and performance monitoring - things that were broken, failing quietly, or just confusing users. So we dropped Sentry’s User Feedback widget straight into the product.

That meant when developers hit friction, their feedback came with all the context we needed like release version, environment, URL, and even a Session Replay of what happened.

The result: Logs evolved faster, got more reliable, and turned into something developers (including us) actually wanted to use.

Turning feedback into features and fixesTurning feedback into features and fixes

The User Feedback Widget wasn’t just a box for collecting opinions, it shaped what we actually shipped during the Logs beta.

One clear example: auto-refresh. Developers kept asking for the log stream to update on its own. We knew it was important but hadn’t prioritized it until the feedback kept piling up in tagged submissions (tip: for a quick view into product-specific feedback, we filter on URL tags). That steady signal pushed it up the queue, and we shipped an auto-refresh feature that’s now live, going from feedback to feature in 4 weeks.

We also heard strong demand for Alerts, leading us to support log-based alerting, so users can get notified when important logs appear, like auth errors or missing configs.

But the widget isn't just for product requests, most importantly it helped surface critical SDK issues that weren’t immediately obvious through error tracking alone. It led us to identify and resolve:

• A bug in the Python SDK where we didn’t collect log attributes properly. When we initially implemented a logging integration with the Python standard library logger we had a bug where we did not attach named parameters to log messages generated by the logging integration. We didn’t realize the API could also be used that way until a user let us know.
  
  

  

  
  

• A JavaScript SDK issue where serialization of certain objects were causing log messages to not render properly. This problem was due to how we were concatenating strings together in the JavaScript SDK to generate logs created via our console instrumentation. The fix was simple, but it was a reminder that it’s easy to let [Object Object] sneak by you sometimes.
  
  

  

  
  

• A deeper bug in the JavaScript SDK that lead to environment and release attributes not being attached correctly to logs. The problem was simple, us not using the right format when attaching these attributes to logs, but it caused a lot of issues for users as our product relies on release and environment values for top level filters and connecting data together.
  

Because feedback submissions include technical context like the environment, organization ID, project name, and URL, we were able to ship fixes across supported platforms and make Logs more reliable for everyone. So Logs behaves as developers expect, both in the frontend experience and within the underlying SDK infrastructure.

Best practices we followed (and recommend)Best practices we followed (and recommend)

• Embed it in‑context: Embed the feedback button directly into high-impact feature areas — so feedback can be submitted where users were already working. We added the feedback button directly in the page header of the Logs stream.

• Use tailored prompts: Contextual placeholder messages like “What was confusing here?” or “How can we make logs work better for you?” lead to more insightful and actionable responses.
  

  

• Tag every submission: Using tags such as feedback.source:new-checkout-screen or feedback.type:negative organizes feedback by feature and sentiment, enabling fast triage.

• Route alerts in real time: Feedback with certain tags or URLs can flow directly into the appropriate channel via alert rules —allowing engineers to see, respond, or fix issues ASAP. For Logs, feedbacks submitted on the url:*logs* were routed to our internal proj-logs Slack channel.

For a full best practices guide, see here.

What we learned and what’s nextWhat we learned and what’s next

We ship quickly at Sentry, but we also ship scrupulously. Embedding feedback right into the product, tying it to Session Replay, and routing it to the right teams meant we could act fast without cutting corners — and help us make decisions with real usage in mind, not just assumptions.

And every so often, amidst the bug reports and feature asks, we’d get a note from a developer just saying they loved what we shipped—which, honestly, is the best kind of validation.

Give Logs and the User Feedback widget a try and let us know what you think on Discord or GitHub. Or, if you’re new to Sentry, get started for free.