Hacker News: nishantmodak

New comment by nishantmodak in "Call a Human MCP"

nishantmodak — Tue, 03 Mar 2026 00:31:31 +0000

I built a small MCP server that lets any AI agent (Claude Desktop, Cursor, Windsurf) block and wait for a human response before taking irreversible actions.

  Two tools:
  - ask_human(question) – agent blocks until you reply
  - request_approval(action) – agent blocks until you click Approve or Deny

  Notifications via Slack (with interactive buttons), or native macOS
  dialogs. Works with any MCP-compatible client over stdio or SSE.

  The use case that motivated it: I kept coming back to find my agent had done
  something I didn't want while I was away. Now it just asks.

  GitHub: https://github.com/nishantmodak/call-a-human-mcp

Call a Human MCP

nishantmodak — Tue, 03 Mar 2026 00:31:31 +0000

Article URL: https://github.com/nishantmodak/call-a-human-mcp

Comments URL: https://news.ycombinator.com/item?id=47226293

Points: 4

# Comments: 1

Why high-cardinality workloads fail differently in Prometheus vs. ClickHouse

nishantmodak — Mon, 19 Jan 2026 20:46:47 +0000

Article URL: https://last9.io/blog/high-cardinality-metrics-prometheus-clickhouse/

Comments URL: https://news.ycombinator.com/item?id=46684277

Points: 3

# Comments: 0

New comment by nishantmodak in "How much of my observability data is waste?"

nishantmodak — Wed, 14 Jan 2026 23:09:08 +0000

Problem has never been the storage. Its running those queries to return in milliseconds - if its for a dashboard, an alert of your new AI agent trying to make sense of it.

New comment by nishantmodak in "Why high-cardinality labels stress metrics databases"

nishantmodak — Thu, 01 Jan 2026 20:57:51 +0000

I wrote this after seeing the same failure modes across multiple teams and metrics stacks.

The intent here isn’t to argue that high cardinality is bad but to explain the mechanical reasons unbounded cardinality shows up later as cost surprises, slow queries, and trust erosion.

Curious if others have seen similar query-time or indexing issues they have noticed.

Why high-cardinality labels stress metrics databases

nishantmodak — Thu, 01 Jan 2026 20:47:02 +0000

Article URL: https://last9.io/blog/why-high-cardinality-metrics-break/

Comments URL: https://news.ycombinator.com/item?id=46457857

Points: 2

# Comments: 1

New comment by nishantmodak in "I am rich and have no idea what to do"

nishantmodak — Fri, 03 Jan 2025 09:23:20 +0000

Wasn't it pascal who said that all of our problems come from our inability to be bored.

New comment by nishantmodak in "Why is observability so expensive?"

nishantmodak — Wed, 03 Apr 2024 21:41:07 +0000

I have a different take

>Engineers have to pre-define and send all telemetry data they might need – since it’s so difficult to make changes after the fact – regardless of the percentage chance of the actual need.

YES. Let them send all the data. The best place to solve for it is at Ingestion.

There's typically 5 different stages to this process.

Instrumentation -> Ingestion -> Storage -> Query (Dashboard) -> Query (Alerting)

Instrumentation is the wrong place to solve this.

Ingestion - Build pipelines that allow to process this data and provide for tools like streaming aggregation, cardinality controls that allow to 'process it' or act on anomalous patterns. This atleast makes working on observability data 'dynamic' instead of having to go change instrumentation always. Storage - Provide blaze (2hours), hot(1 month), cold(13 months) of tiered data storage with indipendent read paths.

This, in my opinion has solved for the bulk of cost & re-work challenges associated with telemetry data.

I believe, Observability is the Big Data of today, without the Big Data tools! (Disclosure: I work at Last9.io and we have taken a similar approach to solve for these challenges)

https://last9.io/data-tiering/