Show HN: Logcat.ai – Observability for Android, Telecom, Automotive System Logs(logcat.ai)
logcat.ai
Show HN: Logcat.ai – Observability for Android, Telecom, Automotive System Logs
https://logcat.ai
4 コメント
this is interesting, but why can't a telecom engineer upload traces and a bugreport into claude to do the same thing? i'm curious to learn more. send me a note if you want to chat.
great question:
1. telecom trace logs are huge in volume. Even the 1M context window won't be sufficient. To give you a perspective - a 2 minute modem activity could lead to 25 million lines of traces.
2. Hypothetically, let's say there ever was a AI model which had enough context window to accommodate that kind of volume, it's still a one shot analysis. Every telecom trace is different (even if taken from same device). There are bursts of errors, there's a ton of noise (more than 80%) and < 20% signal. LLMs can't differentiate between the two.
3. Telecom traces can be proprietary, requiring dedicated on-prem solutions that only SaaS can deliver. Further, a SaaS approach is essential to meet enterprise requirements, guarantee accuracy and consistency, and most importantly integration into engineering workflows - because, at the end that's the important point, which is to reduce the time spent by engineers in an org on mundane tasks.
4. For bugreports, the same logic applies. One-shot analysis is insufficient and causes hallucinations. In addition, Android bugreports are super fragmented - OEM variations, Android variations, proprietary Android changes and their logs, huge volume of logs and the need for orchestration, dedicated focus on the fast evolving Android landscape (1 new release every year).
General purpose AI models can never meet the requirements of specialized, mission critical domains that logcat.ai targets.
1. telecom trace logs are huge in volume. Even the 1M context window won't be sufficient. To give you a perspective - a 2 minute modem activity could lead to 25 million lines of traces.
2. Hypothetically, let's say there ever was a AI model which had enough context window to accommodate that kind of volume, it's still a one shot analysis. Every telecom trace is different (even if taken from same device). There are bursts of errors, there's a ton of noise (more than 80%) and < 20% signal. LLMs can't differentiate between the two.
3. Telecom traces can be proprietary, requiring dedicated on-prem solutions that only SaaS can deliver. Further, a SaaS approach is essential to meet enterprise requirements, guarantee accuracy and consistency, and most importantly integration into engineering workflows - because, at the end that's the important point, which is to reduce the time spent by engineers in an org on mundane tasks.
4. For bugreports, the same logic applies. One-shot analysis is insufficient and causes hallucinations. In addition, Android bugreports are super fragmented - OEM variations, Android variations, proprietary Android changes and their logs, huge volume of logs and the need for orchestration, dedicated focus on the fast evolving Android landscape (1 new release every year).
General purpose AI models can never meet the requirements of specialized, mission critical domains that logcat.ai targets.
also, not sure how to send a note on HN hah. I don't think there's a DM feature on this platform
Since then I left my job and have been building full-time. 400+ organic signups, paying customers across telecom, automotive, and device management. Time for a proper Show HN.
The problem: I've spent 13 years in Android OS internals (AOSP, LineageOS, founding engineer at Esper) and the debugging workflow has never meaningfully improved. You get a 100MB bugreport zip with 20+ files and spend hours ctrl+F'ing timestamps trying to correlate logcat with kernel logs with dumpsys with radio logs. Telecom engineers have it worse because they're also juggling QXDM modem traces. Automotive teams pile VHAL and CAN bus on top of all that.
What logcat.ai does: Upload the files you already have and get a root cause analysis with a correlated timeline across layers (app, framework, HAL, kernel, modem). No SDK, no agents, nothing to install.
How people actually use it: Telecom engineer uploads modem traces alongside a bugreport to figure out why VoLTE calls drop during handovers. MDM company uploads bugreports from fleet devices to triage field issues without reproducing them. Delta mode: upload two bugreports (working vs broken), get a structured diff of what changed without all the noise. Deep Research: autonomous multi-pass investigation that follows causal chains across log sources.
What's interesting technically: The hard part is preprocessing. A 200MB bugreport needs heavy denoising and intelligent chunking before an LLM can reason over it. Every other log type comes with its own challenges and then there is a mix of all of them. We use AI for human readable representation of the analysis and interaction. Currently supports bugreports, logcat, dmesg, tombstones, ANR traces, modem log exports from QXDM/QCAT or Mediatek's/Samsung's modem log outputs.