Upstash Status Status Page

Jun 25, 2026 · resolved Jun 25

This incident has been resolved, we will publish RCA soon.

Jun 23, 2026 · resolved Jun 23

### **Summary** On June 23, 2026, QStash users in the EU-CENTRAL-1 region experienced elevated latency and degraded performance. The issue was caused by a regression introduced in a recent enhancement to Flow Control scheduling logic. The change increased resource consumption under load, leading to reduced performance on affected shards. The incident was resolved by rolling back to the previous stable version. ### **Impact** * Service: QStash \(EU-CENTRAL-1\) * Start: 2026-06-23 16:22 UTC * Resolved: 2026-06-23 17:14 UTC * Duration: ~52 minutes * Impact: Increased latency and degraded performance for workloads routed to the affected instance in the EU. Multiple customers in the region experienced slower request processing during the incident window. ### **Root Cause** We recently deployed an enhancement to our Flow Control feature, designed to improve fairness between independent flow controls when unused global parallelism capacity was available. Under production load, the new behavior introduced a regression that significantly increased resource utilization. The elevated resource consumption caused performance degradation on the affected QStash instamce, impacting all workloads sharing that instance. ### **Resolution** After identifying the regression as the source of the slowdown, we rolled back the deployment to the last known stable version. * Rollback completed: 2026-06-23 19:18:46.84 UTC Following the rollback, system performance returned to normal levels and service stability was restored. ### **Preventive Actions** To reduce the likelihood of similar incidents in the future, we are taking the following actions: * Expand performance and load testing coverage for Flow Control changes. * Add resource utilization regression checks to the deployment pipeline. * Improve monitoring and alerting for abnormal CPU and memory consumption patterns. * Introduce additional canary validation before wider production rollout of scheduler-related changes. We apologize for the disruption and appreciate our customers’ patience while we resolved the issue.

Jun 23, 2026 · resolved Jun 23

Between 01:18 and 04:03 UTC, customers were unable to access running boxes or perform create, read, update, or delete operations. Running containers were not affected and continued operating throughout. The issue has been fully resolved and all box operations are functioning normally. We are taking all necessary measures to prevent this from happening again. We apologize for the disruption.

Jun 19, 2026 · resolved Jun 19

## What happened A configuration change applied to QStash's EU networking layer introduced an outbound connectivity fault. Between **09:11 and 09:45 UTC**, a subset of QStash instances had degraded egress connectivity, and some dispatched messages may have failed on their initial attempt. A related side effect caused some servers to egress from IP addresses outside QStash's advertised outbound range until **11:24 UTC**; during that window, endpoints enforcing QStash IP allowlists may have rejected requests from those servers. QStash's automatic retries delivered many affected messages on subsequent attempts once connectivity was restored, and QStash is now operating normally. ## Customer impact Impact was limited to the EU region and to two effects within the window above: * **Delivery delays / failures** _\(09:11 – 09:45 UTC\)_ — messages dispatched through affected instances may have failed on their first attempt. Thanks to automatic retries with backoff, most were re-delivered once connectivity recovered; messages that exhausted their retry policy during the window followed their configured failure path \(e.g., DLQ / failure callback\). * **Allowlist rejections** _\(09:11 – 11:24 UTC\)_ — customers who restrict inbound traffic to QStash's outbound IP ranges may have seen requests from the affected servers rejected. Customers who do not enforce source-IP allowlisting were unaffected by this. ## Root cause A routine networking configuration change contained an error that: 1. disrupted outbound connectivity on the affected nodes, and 2. caused affected nodes to acquire outbound IPs outside the advertised range. The underlying gap was systemic: the change procedure had no automated validation gate to catch the faulty state before it reached production. ## What we've done * **Fail-fast pre-checks** — automated validation now halts the change procedure _before it runs_ if a configuration would degrade connectivity or violate expected state. * **Egress IP-range enforcement** — outbound IP assignments are now checked against the advertised QStash range, so a node can no longer come online with an unadvertised IP. * **Tighter post-change verification** — completion now confirms outbound reachability and egress-IP conformance across affected nodes. ## Customer action None required. All QStash traffic again originates from the advertised outbound IP ranges. We apologize for the disruption.

Jun 4, 2026 · resolved Jun 4

This incident has been resolved.

Is Upstash Status down right now?

No — Upstash Status is up. All systems operational as of Jul 13, 11:43 PM UTC.

What is Upstash Status's current status?

Upstash Status: All Systems Operational. Alert24 checks Upstash Status's status page continuously and can notify you the moment it changes.

How do I get alerted when Upstash Status goes down?

Alert24 monitors Upstash Status and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.