Apologies, for all the thought put in to balancing conciseness with completeness, that was a bad miss. Right now we are focusing on Go and Java. We're flexible on logging libraries - if you have strong prefs here, we'd love to get that signal.
Moving forward we will be able to support Python, Ruby, TypeScript, JavaScript, Scala, and Kotlin as well.
I'll check the page issue on firefox. Thanks for the flag.
Thanks! Yeah, we're finding a lot of interest from small teams who want to move fast without accumulating tech debt / creating a negative trend between customer count an reliability as they start to find traction themselves.
Want to drop us an email (founders@getpatchwork.io)? Right now we do our best to make pricing work for our customers because the real value for us in this early stage is your feedback. (Cliche but true :) )
Thanks for the support, it means a lot to us! It would be a dream to see our products working together in the near future. Here's to a high-context future of debugging :)
The folk at Patched are doing great work - they are our YC batch mates! Alas, we cannot take credit for that write-up, sadly, nor answer the question re their source code. We are getpatchwork.io / Patchwork Technologies.
Thanks for pointing this one out, we weren't aware it could do that. Do you use those features yourself? We think it's an important enough problem that there's room for multiple people to be solving it, but very curious to hear if you think they have.
On the OSS piece, we are not ignoring this. It's very early days for us so we are figuring out how best to balance our limited resources and, in the future, make a thoughtful contribution to the community.
(Edit: just clocked that you _are_ OneUptime.com, so some of my questions won't make total sense. We'd love to understand how your users have responded to those capabilities, if you're willing to share)
Glad to hear that resonates. Goes without saying that we get the best reception with people who've literately done manual surges on this. Speaking from experience?
> Refactoring the logs in existing code bases today is a manual slog.
slog is shorthand for structured logs[1][2][3][4]. So refactoring the logs [without a tool] is manually converting them to a slog. You have a great pun on your hands.
> Speaking from experience?
I have a notebook laying around with a loose plan on how to get the most compression possible out of a log file. It would use ML to figure out what the log strings would be - but I think your idea of scanning the executable is even more clever. Anyway, once it knows the log strings you can probably stuff it into off the shelf column storage for great compression rates. And if the compression rates are good enough then searches should be much much faster as well.
Who do you reckon are the more important existing competitors? Grafana labs or Sonarqube?
Ahah. Totally missed that, I will admit. I gratefully accept the pun and will be using it even more going forward.
If you're willing to chat on the technical details of that notebook, we'd love to. Of course, if you're hoping to build it one day and don't feel comfortable sharing, understand. If yes, it's founders@getpatchwork.io :)
We are definitely eyeing up what can be done when you control the log strings and the rest of the payload. And along the lines of what you say, our first step would be to see how much ClickHouse could squeeze that, and then see what other clever compression could be added in advance.
Anyone crushing it in the code analysis and refactoring space is a challenger. I think for now our sense is that the full-blown agentic SWE tools have bitten off more than they can chew and aren't viewed as credible just yet. However there are people out there taking a focused, use-case-specific approach (like us) who are building impressive things. komment.ai is one that springs to mind. SonarQube looks interesting - thanks for flagging.
In terms of logging stack players, we're hoping some could be friend rather than foe, at least to begin with. We thought ClickHouse might see unstructured logs as an unlock for their customers / GTM motion. However, they have invested a lot in their query-time materialisation tech, which they said their log storage customers love. Expensive, in practice, I suspect. Grafana actually pinged me yesterday.
Thanks for flagging that one. It has turned out to be a very busy namespace. We're focusing on making sure the product sticks first... then figuring out if the name needs changing is a good problem to have! :D
Possibly yes! If I had a project running in production with a team this seems very valuable as another layer of defense. With these kinds of scanning tools however, they are quickly ignored if they tend to emit noise. If at all possible (from a cost perspective) I'd focus on launching a free version for open source projects complete with a badge to add to the readme. Similar to other Linting/CI projects. Might help gain a bunch of traction in the short term, and if it's free folks may be likely to add it and leave it even if the accuracy isn't perfect which may be nice marketing for y'all.
Also... can you expand this to comments? Doesn't seem too different from logs. And then add in the fairly obvious auto-PR logic with the ability to respond to PR comments and now you're eliminating maintenance burden. Caveat: I dunno if anyone else is doing this, but this seems like a promising step.
We're thinking alike. While we're iterating with customers, we're also thinking about how we can use it to contribute beneficially to projects (and in doing so prove it works reliably). One thing we are keeping a list of is popular OSS repos with notoriously spammy logs - if you know any, please let us know! We are planning to start with some of our YC batch mates' OSS projects once we get the quality right. I won't say exactly when we started showing the "fixes" but it was _very_ recently. Ensuring accuracy on identifying exceptions to the rules (aka the appropriate statements to touch in the first place) is the first thing we are perfecting.
We could expand to comments. The code maintenance direction is a possibility but the reason we get out of bed right now is to make a worthy contribution to logging -> debugging -> SRE sleep :)
Understood. The landing page so far is taking a back seat relative to making the product better for our early customers, which I'm sure you can appreciate. We hope to open source components of the product. In the mean time are there specific parts of the technical approach that you'd like us to see better described?
Structured/JSON saves a tonne of time building regex parsers. The regex parsing at query-time is also pretty expensive. This is where Splunk excels - dealing with the noise with powerful querying. ClickHouse is also very performant at this, we hear. It's an expensive task though (computationally and cost wise)
Charity, CTO of Honeycomb has strong views (which we enjoy a lot): https://charity.wtf/tag/observability-2-0/ - they come at it from a tracing/OT angle which is Honeycomb's forte, but we agree a lot on the intended outcomes - actionable (not spammy/noisy) + make it easy to gather the variable/state context in the context of a single event.
Moving forward we will be able to support Python, Ruby, TypeScript, JavaScript, Scala, and Kotlin as well.
I'll check the page issue on firefox. Thanks for the flag.