Parseable

Observability infrastructure for agents, apps and systems. Try out now at

[Parseable @parseablehq]

Let's talk rows and columns.

Do you use or know the Parquet file format?

In this -- Explain Parquet like I'm Five -- article, we dissect the file format, its benefits and uses, and why it's a great fit for logging systems like Parseable.

https://t.co/AKWjop90A9

[Ryan Djurovich 😎 @ryan0x44]

@gokulr For observability I think @OpenObserve and @parseablehq are really onto something. Open Source. Parquet in object storage. But you'll use Cloud because you want compliance and reliability and it's priced appropriately.

[Nitish Tiwari @nitisht_]

Read here: https://t.co/QcYHvGkiXz

[Nitish Tiwari @nitisht_]

When should you use; wide events vs logs, metrics and traces? I wrote a decision framework.

> Metrics tell you something is wrong.
> Wide events tell you exactly what went wrong and why.
> Wide events however come at a hefty price tag.
> Cost is a storage architecture problem, not a data model problem.

[Nitish Tiwari @nitisht_]

When you get paged, and you're trying to find what's happening; most of the times the trace / log overview page is not the best place to be.

You want to see all the errors and then work your way back to the traces & logs. Because error messages tell a story of what, how and when.

Based on several users input, we built Parseable Error page.

> Errors grouped by exception type, message & stack trace
> Spark charts show if it's a burst or a chronic issue
> AI summary gives you root cause + fix checklist before you read a single stack frame
> One click to correlate with logs or escalate to Keystone

https://t.co/8Ehgfzbafi

[Nitish Tiwari @nitisht_]

We got great responses to our GTM Engineer post and found the right person for that role. Thank you to everyone who reached out.

Now hiring for a another key role: Founder's Office Associate with a GTM focus.

We're building the first purpose-built observability datalake for the agentic era. Backed by Surge.

Looking for someone who is:
> Keen to run experiment cycles end to end — outreach, discovery, demos.
> Can build and iterate on positioning, content, and outbound strategy
> Can own the messy middle between product, customers, and market
> Comfortable with ambiguity. Fast with AI tooling. Allergic to busywork.

This is a strategic hire for us. At our stage, GTM decisions are company-defining — who we sell to, how we position, what the first 5 minutes of the product feel like. But strategy without output is useless. You'll be measured on what you ship, not what you present.

In-person, in office, BLR. Early equity. High leverage, steep learning curve.

DM me.

[Nitish Tiwari @nitisht_]

This is spot on. The missing piece in most "context graph" discussions: where does this data actually live?

Capturing decision traces is step one. Storing them in open, queryable formats that agents can freely inspect is step two.

If the trace data ends up in yet another proprietary system with its own custom query language, convoluted API access and cost barriers, you've rebuilt the silo, bigger this time.

The compounding loop only works when the data layer is genuinely open.

[Nitish Tiwari @nitisht_]

Excited to announce Parseable Auto Instrumentation aka π PAI.

If you've ever set up OpenTelemetry for a Kubernetes cluster, you know the drill: write collector configs, wire receivers, processors, exporters, pipelines — for every signal, every namespace, every environment. It works, but it's a lot of YAML to maintain before you see a single log line.

PAI is a Kubernetes operator that does all of that for you, automatically. You define what you want to collect and where to send it. PAI handles the rest.
A single CRD for four signals.

- Logs collected from every node via filelog receiver, enriched with pod, namespace, and container metadata
- Metrics from pod and node-level CPU, memory, network via kubeletstats and k8s_cluster receivers
- Traces with zero-code auto-instrumentation for Java, Python, Rust, Go, Node.js, and .NET via OTel SDK injection.
- Kubernetes cluster events streamed in real time

PAI manages the full lifecycle of all the underlying OpenTelemetry resources. When you delete the CR, everything is cleaned up automatically.

We built this because the gap between "OTel Operator installed" and "data flowing into Parseable" was too wide. PAI closes that gap.

It's open source.
👉 GitHub: https://t.co/xcCRLqNrwq

Would love feedback from anyone running OTel at scale -what signals matter most to you, what's missing, what's painful.
#OpenSource #Kubernetes #Observability #OpenTelemetry #Parseable #DevOps #Platform

[Parseable @parseablehq]

𝗔𝘅𝗶𝗼𝘀 𝗦𝘂𝗽𝗽𝗹𝘆 𝗖𝗵𝗮𝗶𝗻 𝗔𝘁𝘁𝗮𝗰𝗸 : 𝗔𝗰𝘁𝗶𝗼𝗻 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗳𝗼𝗿 𝗣𝗮𝗿𝘀𝗲𝗮𝗯𝗹𝗲 𝗢𝗦𝗦 𝘂𝘀𝗲𝗿𝘀

The 𝘢𝘹𝘪𝘰𝘴 npm package was compromised today via a hijacked maintainer account. Malicious versions 1.14.1 and 0.30.4 silently deploy a cross-platform RAT through a phantom dependency. With 300M+ weekly downloads, the blast radius is massive.

𝗣𝗮𝗿𝘀𝗲𝗮𝗯𝗹𝗲 𝗖𝗹𝗼𝘂𝗱 𝘂𝘀𝗲𝗿𝘀: 𝗻𝗼 𝗮𝗰𝘁𝗶𝗼𝗻 𝗻𝗲𝗲𝗱𝗲𝗱. Our cloud infrastructure was not compromised. We have verified that no malicious payloads were executed or injected into any cloud environment. Your data and systems remain safe.

𝗣𝗮𝗿𝘀𝗲𝗮𝗯𝗹𝗲 𝗢𝗦𝗦 𝘂𝘀𝗲𝗿𝘀: 𝗽𝗹𝗲𝗮𝘀𝗲 𝘂𝗽𝗴𝗿𝗮𝗱𝗲 𝘁𝗼 𝘃𝟮.𝟲.𝟱 𝗶𝗺𝗺𝗲𝗱𝗶𝗮𝘁𝗲𝗹𝘆. Earlier releases included the affected axios version in the dependency tree. We've now pinned axios to a known safe version and shipped the fix in v2.6.5.

For your broader stack, check lockfiles for 𝘢𝘹𝘪𝘰𝘴 v1.14.1 or v0.30.4, look for 𝘱𝘭𝘢𝘪𝘯-𝘤𝘳𝘺𝘱𝘵𝘰-𝘫𝘴 in 𝘯𝘰𝘥𝘦_𝘮𝘰𝘥𝘶𝘭𝘦𝘴, and rotate credentials on any affected systems.

#supplychain #security #axios #npm #opensource #observability #parseable

[Nitish Tiwari @nitisht_]

Hiring: GTM Engineer at Parseable (founding team)

We're building the first purpose-built observability datalake for the agentic era. Backed by Surge.

Looking for someone who can:
→ Build working demos and PoCs, not slide decks
→ Use AI to generate demo environments and automate onboarding
→ Think in adoption curves, not sales pipelines

Technical enough to write code. Strategic enough to think about how products spread inside orgs.

Early equity. Small team. Big surface area.

DM me.

[Nitish Tiwari @nitisht_]

Watched a dev debug a production issue last week. They found the error log by filtering, and without much deliberation, pasted the error into Claude, asked it to find the underlying issue, and had a root cause in 4 minutes. The debugging workflow is changing faster than the tools are.

[Parseable @parseablehq]

Pick a service from the dropdown. Set your time range. Done.

Try it out today at https://t.co/UumUBtEBq8

#Observability #OpenTelemetry #DevOps

[Parseable @parseablehq]

Debugging distributed systems usually means switching between 4 different dashboards.

We just shipped Insights in Traces to fix that. Here's what it looks like

[Parseable @parseablehq]

One view per service gives you:
- Requests & errors over time
- Latency percentiles: P50, P75, P90, P95, P99, Max
- Error breakdown by status code (500, 503, 504)
- Resource table with requests, duration, P95, error rate

[Nitish Tiwari @nitisht_]

Observability migrations are technically simple. Pointing ingestion at a new system takes minutes if not hours. However, everything around the data takes quarters - alerts, dashboards, query translation, historical data extraction. That's not by accident.

Proprietary storage formats and custom query languages are retention strategies. The harder it is to leave, the less competitive the renewal price needs to be. Teams stop evaluating. They absorb price increases. They reduce retention windows rather than reconsider the stack.

We've helped several teams move off other platforms over the last six months. LLMs have been surprisingly useful here - translating legacy query logic, rebuilding dashboard configs, mapping alert rules. One of the more practical LLM use cases we've seen work.

If you're looking to migrate: https://t.co/3A0lXIQnMT

[Nitish Tiwari @nitisht_]

https://t.co/dzb4tsGicA

[Nitish Tiwari @nitisht_]

As volumes and use cases grow, data remains the moat in AI era.

[Himank @HimankChaudhary]

Logs keep growing. Traditional observability stacks struggle.

@parseablehq flips the model - building an observability data lake for agents, LLM workloads, and infra telemetry using an object-storage-first architecture on Tigris.

https://t.co/u7O8kgYMit

[Ovais Tariq @ovaistariq]

It's been fun watching @parseablehq build an observability data lake on top of Tigris.

They are basically enabling "AI-grade observability": model behavior, quality signals, token usage, and infra telemetry all in one place: https://t.co/9TFqJL5Bwt

[Nitish Tiwari @nitisht_]

We're looking for a growth and marketing expert to join our marketing team at Parseable, focused on developer and SRE audiences. You'll work on real world problems, shape how developers and SREs discover and adopt Parseable.

What you'll do:
- Content strategy and execution (blogs, social, community)
- Demand generation and developer outreach
- Positioning, messaging, and go-to-market experiments
- Campaigns around launches, events, and partnerships

Skills we're looking for:
- Think and write independently
- SEO and organic growth strategies
- Community building and developer engagement
- Email marketing and nurture campaigns
- Tracking funnel metrics, attribution, and campaign performance

This is a high-impact role at an early stage. You'll shape how the world discovers Parseable.

📍 In office (Whitefield, BLR) | ⌛ Full time

Interested? email me at nitish [at] parseable [dot] com.

#HiringAlert #marketing

[Nitish Tiwari @nitisht_]

Parseable is a telemetry datalake on object storage. Logs, metrics, traces, and AI agent telemetry go into one system, stored as open Parquet files on object store. You query with SQL or natural language. You keep data for 12 months instead of 30 days. You pay 80x lesser.

Some context on why we built this.

Observability costs grow linearly with data volume, but value doesn't. Most teams delete telemetry after a month because their platform makes retention irrational. AI workloads are making this worse — agents generate telemetry at extreme volume and cardinality, and that data is scattered across separate tools that don't correlate with each other.

We spent the last year talking to engineering leaders about this. 75% cited cost as their primary observability concern. 84% of organizations plan to consolidate tools in 2026. The pattern was clear: teams are paying more each year, retaining less data, and getting slower queries.

@parseablehq fixes the economics by fixing the architecture. Columnar Parquet format compresses telemetry up to 90%. Compute and storage scale independently. No pre-indexing, no write amplification, no JVM overhead. The entire engine is written in Rust and runs on @TigrisData , a globally distributed S3-compatible store with zero egress fees.

Pro plan is $0.39/GB ingested. 12 months retention. All AI features included — natural language queries, forecasting, anomaly detection. Unlimited hosts, users, dashboards. 14-day free trial, no credit card.

Enterprise gets bring-your-own-bucket for unlimited retention, data residency, BYOC or on-prem deployment, and Iceberg support.

Self-hosted is still available. Single binary. Same engine.

If you're running AI workloads alongside traditional infrastructure and tired of stitching together three tools to understand one incident, try out Parseable today at https://t.co/jBohLqK1kN