Show HN: Pbar.io – Distributed progress bars that work in terminals and browsers (pbar.io)

I got "Error Progress bar not found" visiting your https://pbar.io/Y8yg3BG link. However, there are no comments yet, so that might explain it. So this is a service you provide.

I must admit that idea behind this project is nice, but I'm not going to get dependent on someone else's infrastructure (and I think I'm not the only one thinking that way), can I host it myself or is the source not available? I don't see any links to sources or github, so decided to just ask here (and to also make the 1st comment here to see if your link would work now).

What does the backend architecture look like? Heavily distributed, or everything in-memory on a single address space server? How do you handle users writing tight loops which fetch the endpoint in rapid fire?

Make number go up

A hierarchical progress bar service is a cool idea in principle, for some tasks state is worth decoupling from process memory. I do note that the homepage example changes colour without real hierarchy shown though! Something worth noting, is that the hierarchy of an important task of some kind might not be known at the start. It's interesting to consider how to have a great developer UX for managing this. I'd probably want MCP support (or a boring OpenAPI). If someone can show in a few lines how a developer can have a messy process get meaningful hierarchy and progress added to it and it's child nodes, without being overly rigid or SaaS externality concerns, that would be really cool, it could perhaps help give feedback on some very intractable problems. People often don't realise that showing useful progress can easily be a really hard distributed systems problem that a lot of real life systems are bottlenecked by. It's interesting that LLMs might actually be able to help ask questions about progress to help better represent what progress should be shown as, asking about subproblems, helping guide the state with structured decision making etc.

This is an incredibly ingenious feature. I'm speechless. It's one of those "I should have come up with it!" things.

Although the practical use case is unclear.

This could really help in some corporate network scenarios, where batch jobs run behind a proxy. That usually rules out pull based monitoring while this seems easy to setup

Really clever, nice work. Love the minimal but polished approach you’ve taken

Very fun, and immediately useful. Also something I haven't seen before? So, kudos on an an ingenious choice of projects.

That being said, I almost immediately ran into 429: Too Many Requests.

Like, yeah, I started making a ton of `{increment: 1}` requests that are getting dropped. What's the bottleneck? Simultaneous DB writes?

Edit: I do want to reiterate that I think this is a great concept, especially in a "Shift Left" era in which agentic tools are exposing non-technical roles to the domain of workflow automation and async job queue management.