getsentry
sentry
Python2012–2026
getsentry / sentry
sentry
Developer-first error tracking and performance monitoring
60Distinct people
88Mentions
0Explicit recommenders
45.8KGitHub stars
What to know before exploring
What it is
Developer-first error tracking and performance monitoring
GitHub
Where it is used
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- getsentry/self-hosted · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year88 dated mentions
Observed mentions: 2012-10-01 16:28:41 UTC to 2026-02-07 15:56:46 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Users and logs provide clues. Sentry provides answers.
What's Sentry?
Sentry is the debugging platform that helps every developer detect, trace, and fix issues. Code breaks, fix it faster.
Official Sentry SDKs
Resources
Documentation
Discussions (Bugs, feature requests,
general questions)
Discord
Contributing
Bug Tracker
Code
Transifex (Translate
Sentry!)
Read the full README on GitHubWhat Hacker News says
6 sourcesHere's what we do at sentry.io :) https://github.com/getsentry/sentry/blob/4cf958535563a6b7443...
In Pre-commit: framework for managing/maintaining multi-language pre-commit hooksWe ran into similar issues at Sentry when trying to unify across platform differences in how C++ compilers emit function names. There is some code in place that tries to clean up function names and trim out the relevant part (eg: just the function name). If someone is curious, this is how this is implemented currently: https://github.com/getsentry/sentry/blob/9681dedd549b64440fe...
For instance it turns `<lambda_7156c3ceaa11256748687ab67e3ef4cd>::operator()` into `lambda::operator()` or things such as `static unsigned int Scaleform::GFx::AS3::IMEManager::DispatchEvent(char const *,char const *,char const *) const` into `Scaleform::GFx::AS3::IMEManager::DispatchEvent`.
Unfortunately the information in the demangled information is in the textual form often not good enough to process it, and the demanglers are so complex that maintaining c
Read the rest
ustom formatters for them is a huge task.
Sentry (https://sentry.io/) | San Francisco, Toronto, Vienna | Software Engineers
Sentry develops an open source application monitoring platform (github.com/getsentry/sentry) that helps software teams identify and debug production errors and performance bottlenecks. We have over $125MM in funding, over 30,000 paying customers, and process close to a billion application events each day. We help software teams from Disney, GitHub, Peloton, Reddit, Atlassian, and countless others ship software more confidently.
We're hiring for a range of positions in San Francisco, Toronto, and Vienna, including full stack, frontend, backend, data engineering, site reliability engineering, etc.
https://sentry.io/jobs
[Edit: oops, my teammate already listed Sentry on this page focusing on Product Management roles. Apologies if this comes off as redundant!]
In Ask HN: Who is hiring? (September 2021)Appreciate your passion here Remi. I don't think a full standardisation of API token formats is ever likely, but I do think there's value in nudging things in that direction.
One big challenge is that it's hard to get service providers to change their token formats. Very few have this at the top of their priority list - they're busy with other things. Here's an example playing out in OSS that is pretty typical: I tried to persuade the (excellent) team at Sentry to update their format, and they essentially told me "we have other priorities" https://github.com/getsentry/sentry/pull/26313. And that's a relatively simple changes, not the adoption of a whole standard.
In addition, as Thomas points out in this article, there are a lot of different token types for someone thinking about minting API tokens to choose between. They might rationally
Read the rest
have different preferences over them. A standard that is prescriptive of format and approach is likely to struggle given that diversity.
With that said, I do see an opportunity here for a more modest standard targeted at service providers that already use JWTs or Macaroons. Generic tokens of those types are relatively easy for scanning providers to identify, and it's easy (and hopefully uncontroversial) for service providers to encode more information in them, like an "if found" link. I think a standard that defines the attribute name there, and the API for reporting / responding, would be a good start that might see adoption.
> You want to 'exploit' F/OSS? That's kind of a sick way to phrase it, no? This is one of the largest, kindest shares of modern human knowledge/artwork in history.
I'm simply using the least charitable language to describe what I'd like to do (and what AWS has already done) -- there's no need to sugar coat. If someone (normally a group of people) has worked hard to create some software, and released this software as open source, and I take to hosting it for profit, I am exploiting their efforts without a doubt if only in the most literal definition-driven sense.
As one would "exploit" natural resources, I would be taking the product of their effort and used it to generate profit. Whether they were kind or noble has nothing to do with it, though of course I agree that F/OSS is one of (if not the) largest and kindest sharing of knowledge i
Read the rest
n human history. I owe my career to F/OSS and the community that powers it (and of course a few schools and teachers along the way), I haven't forgotten.
What I was trying to point out is that it's relatively easy for me to make a decision to give back 10/20/30+% of revenue (never take % shares of profit, see the movie industry) as a bootstrapper, where companies who are VC funded may not be able to make such a choice easily because they have other capitalists to answer to.
> Don't _exploit_ the generosity of other people. Use it and contribute back to it. Framing it as something to exploit really emphasizes the need for the GPL.
This is very close to my point -- if you don't want this to happen (no matter what someone calls it), pick the appropriate license -- BSSL or a similar license. Do not depend on the kindness of strangers, it's not a good long term strategy -- the GPL was invented to give that ideology teeth and it's been outrageously successful.
Sentry, a well known and liked player in the error reporting space does so[0]. People use Sentry, and contribute to it, and love it. People who think picking GPL licenses will offer the same protections are somewhat misguided, the closes you can get is AGPLv3 which to be honest isn't even right, because hosting unmodified versions seemed to be permitted.
I call it exploitation because that is what you have to assume that companies (which exist for a very specific reason in just about every economy in the world) will almost certainly skew in the direction of exploitation, they are basically duty-bound to do so.
[0]: https://github.com/getsentry/sentry/blob/master/LICENSE