A round-up of recent work on StreamBoost. Most of it concerns the order lifecycle — how an order is tracked, continued and finished — which is the part of the platform that most directly decides whether you get what you paid for.
Partially delivered orders now continue
A partially delivered order used to be treated as finished. It is not: it is an order with quantity still owed. Where the fulfilment system supports continuation, a partial order now stays active and StreamBoost keeps asking it to continue until the requested quantity is delivered.
Your order page reflects that directly — such an order reads Partially delivered — continuing rather than anything that looks like a dead end.
- Partial orders remain in the active work queue instead of being filed away.
- Continuation asks the existing job to carry on; it never creates a second job.
- Orders that genuinely cannot progress are set aside for a person rather than retried forever.
Live order progress
Order progress now updates on the page as delivery happens, without a refresh. Delivered count, remaining, percentage and status all move by themselves.
Your browser holds one authenticated connection to StreamBoost and talks to nothing else. If that connection cannot be established — a network that blocks long-lived connections, for instance — the page falls back to refreshing periodically, so it stays accurate either way.
Clearer cancellation
Cancelling an order now removes it from active processing immediately and completely: it stops being checked, stops being continued, and releases its slot in the work queue. The record itself is kept, with its price, delivered quantity and full timeline intact.
A cancellation reported by the fulfilment system itself produces the identical result, so the two are indistinguishable afterwards.
Outage handling
An unreachable fulfilment system no longer looks like a stalled order. Affected orders show Waiting for provider, keep their progress, and resume automatically on recovery — they are not failed and not refunded, because an outage is information about that system rather than about your order.
A rebuilt public site
The pages outside the dashboard have been written properly, and every footer link now goes somewhere real.
| Page | What it now covers |
|---|---|
| Features | What the platform actually does, without roadmap items |
| Pricing | The prepaid model and the real top-up amounts |
| Status | Live checks, with no invented uptime figures |
| Privacy, Terms, Security, Cookies | Written from the implementation rather than a template |
| Support | A Help Center alongside the existing ticket system |
Under the hood
- Fulfilment systems are health-checked continuously, and orders belonging to an unreachable one are set aside rather than repeatedly failed.
- Retries follow a fixed backoff ladder, and any success resets it immediately.
- A status read that arrives after an order has been cancelled is discarded rather than applied, so a cancelled order can never be put back into a running state.
- The integration specification for fulfilment systems now documents the exact request for every endpoint.
A shorter, structured view of the same ground:
See the changelog