---
name: QStash Released
slug: upstash-qstash-released
type: feed
source_url: https://github.com/orgs/upstash/discussions/categories/q-released
organization: Upstash
organization_slug: upstash
total_releases: 9
latest_date: 2026-04-01
last_updated: 2026-04-19
tracking_since: 2025-11-05
canonical: https://releases.sh/upstash/upstash-qstash-released
organization_url: https://releases.sh/upstash
---

<Summary type="rolling" window-days="90" release-count="6">
QStash overhauled flow control to become a runtime-managed feature rather than a publish-time configuration. The rewrite addressed a core usability issue where cancelling rate-limited messages left slots blocked, making the feature practically unusable—now messages sit in an ordered wait list instead of being pre-scheduled to future slots, so cancellations free capacity immediately for new publishes. Alongside this, the team added pause/resume operations and an API to pin rate and parallelism values outside the publish path, plus expanded the flow control metrics endpoint to surface waitlist depth, active task counts, and effective limits so users can diagnose why messages queue. Two other threads emerged: sensitive data protection via field-level redaction in publish calls (body and header whitelisting), and regional expansion with US and EU endpoints to reduce latency.
</Summary>

<Summary type="monthly" period="March 2026" release-count="5">
QStash expanded flow control capabilities and added data protection features. The team shipped pause/resume controls for flow-control keys, a new API to manually pin and adjust rate and parallelism settings without republishing messages, and enhanced the get flow-control endpoint with detailed metrics showing parallelism count, rate usage, and waitlist size to help users monitor limits. Sensitive data redaction also shipped, letting developers mark message bodies and specific headers to be redacted from the dashboard and API responses. Regional expansion to US and EU endpoints reduced latency for message ingestion.
</Summary>

<Release date="April 1, 2026" published="2026-04-01T09:07:38.000Z" url="https://github.com/orgs/upstash/discussions/177">
## Cancel Messages Related To A Flow-Control

Problem:

Cancelling a message the Flow-control does not take affect immediately. Especially with the `rate` option. In the current implementation, with the `rate`, The messages are scheduled to fire in the future. Because of this implementation, the cancel is recorded `CANCEL_REQUESTED` for all these messages and only `logged` as `CANCELLED` when the schedule time hits.

Another big problem is that, when you want to fire a new message with the flow control, all the slots in the future is already taken by -soon to be cancelled- messages. This makes cancel effectively unusable.

Solution:

The flow control is rewritten to take the `CANCEL` into account sooner. And new messages does not need to wait for old slots to be opened.

Details:

With the new implementation, the messages are not scheduled to the future but put to a ordered `wait list` to be fired when the `flow control` limit allows. When a flow control is cancelled. Again all the messages in progress are marked as `CANCEL REQUESTED`.

The new messages are immediately put to `wait list`. When a flow control limit is opened and `waitlist` needs to be consumed, the `CANCEL REQUESTED` messages are all `CANCELLED` immediately. This allows, new messages in the wait list are fired  immediately as well.
</Release>

<Release date="March 31, 2026" published="2026-03-31T11:38:52.000Z" url="https://github.com/orgs/upstash/discussions/188">
## Sensitive Data Redaction On Console/API

QStash messages may contain sensitive data in the body or headers. Users need a way to redact these fields so they are not visible in the dashboard or API responses, preventing accidental data leaks. This also enables safer use of QStash in multi-tenant setups where customer data may be included in messages.

## API

Allow specifying fields to redact when publishing a message.

" });

const res = await client.publishJSON({
  url: "https://my-api...",
  body: { hello: "world" },
  redact: {
    body: true,
    header: ["Authorization"] // or `header: true` to redact all headers
  },
});">import { Client } from "@upstash/qstash";

const client = new Client({ token: "" });

const res = await client.publishJSON({
  url: "https://my-api...",
  body: { hello: "world" },
  redact: {
    body: true,
    header: ["Authorization"] // or `header: true` to redact all headers
  },
});

In this example, the message body and the "Authorization" header are redacted and will not appear in the UI or API responses. Instead, the UI will display `REDACTED:` so users can verify the value without revealing the original data.

Docs: [https://upstash.com/docs/qstash/howto/redact-fields](https://upstash.com/docs/qstash/howto/redact-fields)
</Release>

<Release date="March 17, 2026" published="2026-03-17T13:10:50.000Z" url="https://github.com/orgs/upstash/discussions/187">
## Flow Control API to change the rate/parallelism manually

Right now, the flow control is only configured with the publish. This makes it hard for our users to change the config when needed from outside.

We will give ability to pin a rate/parallelism to a flow-control. This way the pinned values will be used instead of the values passed via the messages.

We will also have an API to unpin the messages.
</Release>

<Release date="March 17, 2026" published="2026-03-17T12:52:36.000Z" url="https://github.com/orgs/upstash/discussions/157">
## Flow Control Pause and Resume

Add ability to pause and resume flow control keys.
</Release>

<Release date="March 6, 2026" published="2026-03-06T08:56:08.000Z" url="https://github.com/orgs/upstash/discussions/167">
## US and EU Region QStash

This is to give much-lower latencies when sending a message via accepting the request from the closest region.
</Release>

<Release date="March 5, 2026" published="2026-03-05T13:03:08.000Z" url="https://github.com/orgs/upstash/discussions/184">
## Flow-Control And Global Parallelism Metrics

Currently it is hard for our users to understand what is going on with Flow-Control/Global Parallellism.

Did it hit the limit?

How many messages are waiting because of the limit?

What is the affective Flow-Control Rate/Parallelism/Period ?

We are revising the Flow-Control implementation. The plan is to improve the get flow-control endpoint as a start to help users more

GET [/v2/flow-control ](https://upstash.com/docs/qstash/api-refence/flow-control/get-flow-control-key)

Current version:

",
  "waitlistSize": 123,
}">
```
{
  "flowControlKey": "",
  "waitlistSize": 123,
}

```

Improved version:

", //  "$" for the messages without flow control. 
  "waitlistSize": 123,
  "parallelism": 10, // If not exists, it means not limited by parallelism
  "parallelismCount": 5, // 5 tasks are running in parallel at the moment
  "rateMax": 10,       // If not exists, it means not limited by rate
  "rateCount" : 4,  //  4 tasks are started within the last period
  "ratePeriod": "1d", 
  "ratePeriodStart": 1708000000 // Unix timestamp when the current rate period started
}">
```
{
  "flowControlKey": "", //  "$" for the messages without flow control. 
  "waitlistSize": 123,
  "parallelism": 10, // If not exists, it means not limited by parallelism
  "parallelismCount": 5, // 5 tasks are running in parallel at the moment
  "rateMax": 10,       // If not exists, it means not limited by rate
  "rateCount" : 4,  //  4 tasks are started within the last period
  "ratePeriod": "1d", 
  "ratePeriodStart": 1708000000 // Unix timestamp when the current rate period started
}

```

To access new fields via SDK -> [https://upstash.com/docs/qstash/features/flowcontrol#get-a-single-flow-control-key](https://upstash.com/docs/qstash/features/flowcontrol#get-a-single-flow-control-key)

There is a special $ wait list on this list that reports the waitlist size for the messages that doesn't have any related flow control key and just waiting for global parallelism.

To access global parallelism info via SDK -> [https://upstash.com/docs/qstash/features/flowcontrol#get-global-parallelism](https://upstash.com/docs/qstash/features/flowcontrol#get-global-parallelism)

You can access all these via rest api as well here: [https://upstash.com/docs/qstash/api-refence/flow-control/list-flow-control-keys](https://upstash.com/docs/qstash/api-refence/flow-control/list-flow-control-keys)

`Flow Control` tab of QStash Console also shows all these data together with the historic global parallelism graph. And there is more detailed version of global parallelism graph on the Usage tab of the QStash Console.
</Release>

<Release date="November 11, 2025" published="2025-11-11T10:12:42.000Z" url="https://github.com/orgs/upstash/discussions/171">
## Request Builder History

Remember last X publishes from the console so that it can be run again easily.

This is aimed for development purposes.
</Release>

<Release date="November 6, 2025" published="2025-11-06T11:36:19.000Z" url="https://github.com/orgs/upstash/discussions/170">
## Flow Control UI

Add ability to list the flow-controls on the console together with their waitListSizes.

Make it searchable.
</Release>

<Release date="November 5, 2025" published="2025-11-05T19:34:56.000Z" url="https://github.com/orgs/upstash/discussions/173">
## Local Development Environment UI

QStash requires a publicly available API to send messages to. During development when applications are not yet deployed, developers typically need to expose their local API by creating a public tunnel. While local tunneling works seamlessly, it requires code changes between development and production environments and increase friction for developers. To simplify the development process, Upstash provides QStash CLI, which allows you to run a development server locally for testing and development.

With this work, the same UI that is given on the console.upstash.com can be used with local server(QStash CLI)

See [https://upstash.com/docs/qstash/howto/local-development](https://upstash.com/docs/qstash/howto/local-development)
</Release>