[HN Gopher] Launch HN: Sift Dev (YC W25) - AI-Powered Datadog Al...
___________________________________________________________________
Launch HN: Sift Dev (YC W25) - AI-Powered Datadog Alternative
Hi HN! We're Kaushik and Ishir. We're building SiftDev
(https://app.trysift.dev/docs), an intelligent logging tool that
understands your observability data in real time, automatically
identifies anomalies, and lets you interact with your logs through
natural language queries. Here's a demo video:
https://www.youtube.com/watch?v=uQ-TTdiu3fc&t=20s, and there's a
demo playground you can try out here: https://app.trysift.dev/. We
used to work on product and engineering at Datadog and Splunk. We
saw how even teams using these industry-leading tools were
struggling to effectively interpret and use their logging data. The
sheer volume of logs overwhelmed experts and newcomers alike,
making it difficult to quickly identify meaningful issues or
patterns. Despite powerful indexing and search capabilities,
developers still had to manually piece together context from
different logs, dashboards, and sources--a tedious and error-prone
process. The "noisy logging" problem--that is, the gap between
overwhelming amounts of raw log data and insights people can act on
--ultimately is a gap between machines (which generate all this
data) and humans (who want and need the insights). SiftDev is built
to bridge that gap and to automate the tedious, manual aspects of
debugging and observability. In marketing-speak: "humans should
never have to look at a log again!" We think people should interact
with their data in terms that make sense on a human level. What
makes SiftDev different is its understanding of application context
over time. While traditional tooling typically lets developers
analyze logs in isolation, or with minimal surrounding context,
SiftDev builds comprehensive profiles of your application's normal
behavior patterns. This awareness allows us to understand what's
truly abnormal versus what might appear unusual in a single
snapshot but is actually expected behavior for your specific
application. SiftDev applies semantic analysis and profiling to
understand your application's logging behavior holistically.
Instead of relying solely on manual search, Sift identifies core
application processes, automatically detects patterns, and surfaces
anomalies, including clear explanations and context. Here are some
examples of what this can look like in practice: Identify core
processes: SiftDev instantly recognizes your payment workflows--
like authorization, capture, and refunds--without manual tagging.
Detect performance patterns: SiftDev learns your nightly batch job
typically handles 10,000 records in 45 minutes, establishing a
clear baseline. Surface hidden anomalies: SiftDev flags silent
failures, such as two microservices updating the same record within
50ms--issues normally hidden by routine logs. You can then
directly ask your logs questions like, "What's causing errors in
our checkout service?" or "Why did latency spike at 2 AM?" and
immediately receive insightful, actionable answers that you'd
otherwise manually be searching for. We'd love for you to test out
our product via our demo playground at https://app.trysift.dev/!
It's a slightly less functional version of our platform but shares
a lot of the core features. Note: we do need users to sign up to do
this but waitlist is optional (of course). We'd love your
feedback, thoughts, and experiences dealing with logging and
observability challenges!
Author : Akula112233
Score : 44 points
Date : 2025-03-11 17:00 UTC (5 hours ago)
| dang wrote:
| [stub for offtopicness]
| kadomony wrote:
| The marketing design approach feels very off to me. You barrage
| me with an annoying scrolling marquee showing me the most
| abstract, unrecognizable logos telling me I should trust you
| because they do. 10+ companies on board feels rather small.
|
| You said AI-driven analysis to identify logs, but I'm already
| skeptical of AI doing tasks like this, and you obfuscate it
| further by not actually showing me how it works, just another
| generic abstract marketing design graphic.
|
| I dunno. It just seems like vaporware-as-a-service from the
| design vibes.
| dang wrote:
| Early-stage startups often have websites that are little more
| than landing pages. That's because a full commercial website
| isn't in their critical path yet--first they need to build
| their product and attract early users, who don't typically
| come in through general web traffic.
|
| That's one reason why Launch HNs usually include a demo
| video. That's the link you should be clicking on if you want
| to see these guys' product. If you do that, you'll see that
| it isn't vaporware.
|
| We also advise startups doing Launch HNs to provide a link
| for users to try the product (preferably without a signup
| gate, but that's not always doable). There's such a link in
| the text above as well.
|
| I suppose one way to avoid complaints about stub websites
| would be not to link to them at all--but then other comments
| would say "why would I trust you, you don't even have a
| website"!
|
| Edit: I've replaced https://runsift.com/ with
| https://app.trysift.dev/docs in the text above. Perhaps that
| will help.
| Velorivox wrote:
| I want to jump in here and post this Launch HN form [0].
| Obviously do not submit it if you are not a YC startup, but
| the questions on there are very helpful in terms of
| thinking about how to post about your startup on HN and
| elsewhere.
|
| [0] https://docs.google.com/forms/d/1pRMkNiD-FKjYL-
| La5JWMwwrcWsp...
| dang wrote:
| There's also https://news.ycombinator.com/yli.html, which
| is the guide for YC startups who want to launch on Hacker
| News. The formal mechanism is YC-only but the principles
| apply more broadly.
| paularmstrong wrote:
| What's not recognizable about Duck, Square, Triangle,
| Asterisk, C, two different cubes, and the letter 'n'?
|
| These, coupled with the random number generator to claim how
| many logs they're processing makes me wonder if the entire
| product is just AI generated slop.
| graphman wrote:
| Is it common practice to display fake realtime numbers on the
| homepage?
|
| let storedNumber = getCookie("countingNumber"); let startNumber
| = storedNumber !== null ? storedNumber :
| Math.floor(Math.random() * (10300000 - 10000000 + 1)) +
| 10000000; let currentNumber = startNumber; function
| updateNumber() { let randomIncrement = Math.floor(Math.random()
| * (275 - 101 + 1)) + 101; currentNumber += randomIncrement;
| element.textContent = formatNumber(currentNumber);
| setCookie("countingNumber", currentNumber, 7); // Save number
| in cookie for 7 days } element.textContent =
| formatNumber(currentNumber); setInterval(updateNumber, 1000);
| Akula112233 wrote:
| Ah! That was a leftover from the initial dev version of our
| website. I've taken it out now. Thank you!
| Jeslijar wrote:
| Hey, maybe you can have a better hiring practice than datadog
| with a 5 question test where if you get a single answer wrong
| in even the smallest of ways you get disqualified from getting
| a job with them for 6 months.
|
| I'm guessing they lost a wealth of great talent due to this
| test on how to support a platform that they give to fresh off
| the street applicants rather than having even a modicum of
| training about their product. They want you to study it for
| free, probably as a marketing tactic - but also so they don't
| have to pay to train employees. it's great like cancer.
|
| Disclaimer: I have never applied to a role with datadog, nor
| interviewed with them. Just had multiple friends complete the
| process with mixed results. Seems like you need to put in ~two
| full weeks of self directed study to pass their on site
| interview 'exam' where they don't tell you about the exam being
| 100% or fail (but it is!)
| waffletower wrote:
| Java bindings would be welcomed by many.
| Akula112233 wrote:
| Absolutely! Java bindings are on our radar. Any specific use
| cases / implementations you'd like to see? In the meantime, we
| do also support a couple off-the-shelf collectors that should
| already support Java applications!
| nextts wrote:
| Funny I was thinking this week logging needs some magic.
|
| Log diving takes a lot of time especially during some kind of
| outage/downtime/bug where the whole team might be watching a
| screen share of someone diving into logs.
|
| At the same time I am sceptical about "AI" especially if it is
| just an LLM stumbling around.
|
| Understanding logs is probably the most brain intensive part of
| the job for me, more so than system design, project planning or
| coding.
|
| This is because you need to know where the code is logging,
| imagine code paths in your head and you constantly see stuff that
| is a red herring or doesn't make sense.
|
| I hope you can improve this space but it won't be easy!
| Akula112233 wrote:
| Very relatable experience with log diving, feels very much like
| a needle-in-haystack problem that gets so much harder when
| you're not the only one who contributed to the source of errors
| (often the case).
|
| As for the skepticism with LLMs stumbling around raw logs: it's
| super deserved. Even the developers who wrote the program often
| refer to larger app context when debugging, so it's not as easy
| as throwing a bunch of logs into an LLM. Plus, context window
| limits & the relative lack of "understanding" with increasingly
| larger contexts is troublesome.
|
| We found it helped a lot to profile application logs over time.
| Think aggregation, but for individual flows rather than similar
| logs. By grouping and ordering flows together, it's bringing
| the context of thousands of (repetitive) logs down to the core
| flows. Much easier to find when things are out of the ordinary.
|
| Still a lot of improvements in regards to false positives and
| variations in application flows.
| ohgr wrote:
| The best way to improve this is to just generate decent useful
| and actionable logs. Sifting through a trash heap is where the
| problem is. No magic will suddenly turn that trash into gold.
|
| You have to do this at the inception of the software you're
| building rather then strap it on the donkey when something
| breaks (the usual way).
| Akula112233 wrote:
| Yep, but it's sometimes a compromise people may be unwilling
| to make. Too often I hear (and have seen via DD customers)
| horror stories about initiatives to fix observability
| squashed by teams in hopes of shipping.
|
| Moving fast has it's downsides and I can't say I blame people
| for deprioritizing good logging practices. But it does come
| back to bite...
|
| Though as a caveat, you don't always have control over your
| logs -- especially with third party services, large but
| fragmented engineering organizations, etc. -- even with great
| internal practices, there's always something.
|
| On another note, access to codebase + live logs gives room to
| develop better auto-instrumentation tooling. Though perhaps
| cursor could do a decent enough job at starting folks off
| ohgr wrote:
| Fuck 'em then. Sorry. There's no excuse for doing a shitty
| job and trying to fix it with another layer of expensive
| tooling over the top.
| vardaro wrote:
| Neat idea. Why logs, and not metrics too? You can characterize an
| accurate "baseline" system behavior through a combination of
| system level and userspace metrics. This profile would offer more
| depth than what you'd otherwise piece together with userspace
| logs.
| Akula112233 wrote:
| Agreed! Metrics are a high priority, especially since working
| to increase the available context around each anomaly we flag.
|
| Logs were a natural starting point because that's where
| developers often spend a significant amount of time stuck
| reading & searching for the right information, manually
| tracking down issues + jumping between logs across services. In
| a way, just finding & summarizing relevant logs for the user
| gave people an easier time debugging.
|
| But metrics will introduce more dimensions to establish
| baseline behavior, so we're pretty excited about it too.
| vardaro wrote:
| I tend to use logs the least when debugging production
| issues. I realize that's a personal anecdote, so I see your
| point.
| evil-olive wrote:
| > SiftDev flags silent failures, such as two microservices
| updating the same record within 50ms
|
| I don't understand, what about that is a "silent failure"?
|
| in order for your product to even know about it, wouldn't I need
| to write a log message for every single record update?
|
| and if my architecture allows two microservices to update the
| same row in the same database...maybe it happening within 50ms is
| expected?
|
| that could be an inefficient architecture for sure, but I'm
| confused as to whether your product is also trying to give me
| recommendations about "here's an architectural inefficiency we
| found based on feeding your logs to an LLM"
|
| > You can then directly ask your logs questions like, "What's
| causing errors in our checkout service?" or "Why did latency
| spike at 2 AM?" and immediately receive insightful, actionable
| answers that you'd otherwise manually be searching for.
|
| the general question I have with any product that's marketing
| itself as being "AI-powered" - how do hallucinations get
| resolved?
|
| I already have _human_ coworkers who will investigate some error
| or alert or performance problem, and come to an incorrect
| conclusion about the cause.
|
| when that happens I can walk through their thought process and
| analysis chain with them and identify the gap that led them to
| the incorrect conclusion. often this is a useful signal that our
| system documentation needs to be updated, or log messages need to
| be clarified, or a dashboard should include a different metric,
| etc etc.
|
| if I ask your product "what caused such-and-such outage" and the
| answer that comes back is incorrect, how do I "teach" it the
| correct answer?
| Akula112233 wrote:
| > I don't understand, what about that is a "silent failure"?
|
| Silent failures can be "allowed" behavior in your applications
| that aren't actually labeled as errors but can be irregular.
| Think race conditions, deadlocks, silent timeouts, or even just
| mislabeled error logs.
|
| > in order for your product to even know about it, wouldn't I
| need to write a log message for every single record update?
|
| That's right, and this may not always feasible (or necessary!),
| but if your application can be impacted by errors like these,
| perhaps it may be worth logging anyway.
|
| > the general question I have with any product that's marketing
| itself as being "AI-powered" - how do hallucinations get
| resolved?
|
| > and if my architecture allows two microservices to update the
| same row in the same database...maybe it happening within 50ms
| is expected?
|
| > if I ask your product "what caused such-and-such outage" and
| the answer that comes back is incorrect, how do I "teach" it
| the correct answer?
|
| For these concerns, human-in-loop feedback is our preliminary
| approach! We have our own internally running to account for
| changes and false errors, but having explanations from human
| input (even as simple as "Not an error" or "Missed error"
| buttons) is very helpful.
|
| > when that happens I can walk through their thought process
| and analysis chain with them and identify the gap that led them
| to the incorrect conclusion. often this is a useful signal that
| our system documentation needs to be updated, or log messages
| need to be clarified, or a dashboard should include a different
| metric, etc etc.
|
| Got it, I imagine it'll be very helpful for us to display our
| chain of thought from our dashboards too. Great feedback, thank
| you!
___________________________________________________________________
(page generated 2025-03-11 23:00 UTC)