Databases / Serverless Redis / Upstash

Upstash

OPERATIONAL

Since Mar 2024 · 50 incidents · status.upstash.com · checked just now

CompareStatus page
GradeA+Last 90 days
A+PRODA+SHIP

Overview

30d90d1y
Admitted uptimeTime not covered by a Sev 1 the provider posted itself. A best case.
100.000%Grade A+
IncidentsEverything posted on the status page except scheduled maintenance.
10 Sev 1
Sev 1 downtimeTotal minutes of Sev 1 incidents, as posted.
0m
Median fixMedian time to resolve. Half of incidents were fixed faster.
0m
LongestLongest single incident, start to resolved.
–
Since lastTime since the last counted incident was resolved.
23d 4h

By area

A+Production
1INCIDENTS
0mAFFECTED
Your users are hit: apps, APIs, databases, inference
Worst, 30d
SEV 2Sep 29, 2026 · 0mBrief connection proxy degradation in us-east-1
Worse. 15 in the last 6 months, 6 in the 6 before.
A+Shipping
0INCIDENTS
0mAFFECTED
You can't deploy, build or manage: CI, CLI, dashboard, auth, billing
Worst, 30dNothing. Nice.
Worse. 3 in the last 6 months, 1 in the 6 before.
CleanSev 3–4Sev 1–2No data

What it costs

One small production database, per month10 GB of data, about 1 GB of RAM on all month, 10M queries a month, one region, no replicas, commercial use. Cheapest plan that runs it.
Redis, pay as you go1 of 4 cheaper
BEST VALUE~$22.25/mo
10M commands at $0.20/100K$20
9 GB storage over the 1 GB free, at $0.25/GB$2.25

Redis, not a relational database. Assumes one command per query. upstash.com · checked Oct 22, 2026 · Wrong price?

Trend, last 12 months

Worse. 18 in the last 6 months, 7 in the 6 before.

Severity mix

Sev 1 · Lights outProd site, API or database down, or data loss0
Sev 2 · BleedingProd degraded or partly down1
Sev 3 · Can't shipCan't deploy, build or manage it0
Sev 4 · PapercutDocs, status page, slow dashboard0

When it breaks

Start times, last 12 months, UTC.

What breaks

N. Virginia, USA (us-east-1)3 incidents
N. California, USA (us-west-1)3 incidents
Redis Global - N. Virginia, USA (us-east-1)3 incidents
Redis Global - N. California, USA (us-west-1)3 incidents
Frankfurt, Germany (eu-central-1)2 incidents
Redis Global - Frankfurt, Germany (eu-central-1)2 incidents

Communication

Updates eachStatus page updates per incident, on average.
2.8Last 12 months
Update gapMedian time between status page updates during an incident.
1h 04mLast 12 months
PostmortemsSev 1–2 incidents with a published write-up.
7 of 21Sev 1–2

Incident history

Show all 28
Sep 29, 20260mSEV 2
Brief connection proxy degradation in us-east-1Sev 2 from the incident title (no components listed)
1 update
  1. 15:12 UTC · resolved
    Between 15:12 and 15:16 UTC, we observed a brief increase in load on the connection proxy layer in us-east-1, which may have affected some existing and new connections. The team responded quickly and resolved the issue. All systems are now fully operational.
Source
Sep 9, 20260mSEV 2
Intermittent DNS Resolution Errors for Upstash Vector in US East (us-east-1)Sev 2 from the incident title (no components listed)
1 update
  1. 12:00 UTC · resolved
    Upstash Vector experienced a brief DNS resolution issue in the US East (us-east-1) region lasting approximately 20 minutes. During this period, new DNS resolution attempts may have failed. Existing connections and clients with cached DNS records were not affected. The issue has been resolved, and DNS resolution is operating normally.
Source
Sep 3, 20260mSEV 4
Upstash Console login issueSev 4 from the incident title (no components listed)
1 update
  1. 08:00 UTC · resolved
    We experienced a brief issue affecting access to the Upstash Console. Our team quickly identified the cause and resolved the issue within minutes. The console is now operating normally.
Source
Aug 28, 20260mSEV 1
Message Persistence Issue — QStash us-east-1Sev 1 from the incident title (no components listed)
1 update
  1. 22:20 UTC · resolved
    Between 22:20 and 22:33 UTC, QStash clients in us-east-1 experienced disruptions related to message persistence. The team applied a fix, and service has been restored.
Source
Jul 22, 20261h 15mSEV 2
Fly.io infrastructure disruption affecting some Upstash Redis databases on Fly.io DFW RegionConnectivity to a subset of Redis databases hosted on Fly.io failed in the DFW region for roughly an hour; others were unaffected.AI-graded · regional
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Connectivity to a subset of Redis databases hosted on Fly.io failed in the DFW region for roughly an hour; others were unaffected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 08:50 UTC · identified
    We are investigating connectivity issues affecting a subset of Redis databases hosted on Fly.io. The issue is related to an ongoing Fly.io infrastructure disruption in the DFW region (https://status.flyio.net/incidents/n4z2my6qw4sb). We are working to restore availability and will provide updates soon.
  2. 09:01 UTC · monitoring
    The affected Fly.io-hosted machines recovered at 08:48 UTC, and service availability has been restored. We are monitoring the systems to confirm continued stability.
  3. 10:05 UTC · resolved
    This incident has been resolved.
Source
Jul 16, 20260mSEV 3
QStash us-east-1 - URL Publish ErrorsQStash URL publish requests failed in us-east-1 during a partial outage of a few minutes; other regions were not mentioned.AI-graded · regional
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 3 · REGIONAL · LOW CONFIDENCE
    QStash URL publish requests failed in us-east-1 during a partial outage of a few minutes; other regions were not mentioned.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
1 update
  1. 06:30 UTC · resolved
    Partial outage due to http parsing errors. Problem was resolved couple minutes later. If problem continues, refreshing the DNS cache is recommended.
Source
Jun 25, 20261h 12mSEV 2
Upstash Redis Partial Service DisruptionUpstash Redis had a partial disruption in three regions (us-east-1, us-west-1, eu-central-1) for about 70 minutes; other regions were not listed.AI-graded · regional · N. Virginia, USA (us-east-1) +5
Why this grade
  1. RULES · SEV 1
    Sev 1 because N. Virginia, USA (us-east-1) had a partial outage
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Upstash Redis had a partial disruption in three regions (us-east-1, us-west-1, eu-central-1) for about 70 minutes; other regions were not listed.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 15:23 UTC · investigating
    We are currently experiencing a partial service disruption affecting Upstash Redis in the following regions: * eu-central-1 * us-east-1 * us-west-1 Our team is investigating the issue and working to restore full service as soon as possible. We will share updates as more information becomes available.
  2. 15:31 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  3. 16:36 UTC · resolved
    This incident has been resolved, we will publish RCA soon.
Source
Jun 23, 202652mSEV 2
QStash EU Region — Degraded PerformanceQStash in EU-CENTRAL-1 had elevated latency and degraded performance from 16:22 to 17:14 UTC on June 23, 2026. Multiple regional customers saw slower request processing. A regression in a Flow Control scheduling change raised resource use on an affected shard. Rolling back to the last stable version restored normal performance.AI-graded · regional · EU-CENTRAL-1 +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because EU-CENTRAL-1 had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · HIGH CONFIDENCE
    QStash queue requests in the EU-CENTRAL-1 region ran slower for about 52 minutes; other regions were not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
4 updates
  1. 16:22 UTC · investigating
    We are currently investigating this issue.
  2. 16:32 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  3. 17:14 UTC · resolved
    This incident has been resolved.
  4. 12:28 UTC · postmortem
    ### **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.
PostmortemSource
Jun 23, 20260mSEV 3
Box Access and Management Operations UnavailableCustomers could not access or manage Upstash Box resources for about 3 hours; running containers kept working.AI-graded · Box
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 3 · UNCLEAR · MEDIUM CONFIDENCE
    Customers could not access or manage Upstash Box resources for about 3 hours; running containers kept working.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
1 update
  1. 06:05 UTC · resolved
    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.
Source
Jun 19, 20260mSEV 2
QStash Service Disruption in the EU RegionA configuration change caused outbound connectivity faults on some EU QStash instances from 09:11 to 09:45 UTC, so some dispatched messages failed on first attempt. Automatic retries re-delivered most. One server used an IP outside the advertised range until 11:24 UTC, so allowlisted endpoints may have rejected its requests. Validation gates were added.AI-graded · regional
Why this grade
  1. RULES · SEV 1
    Sev 1 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    QStash message dispatch in the EU region degraded for 34 minutes, with some deliveries failing and allowlisted endpoints rejecting requests until 11:24 UTC.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
2 updates
  1. 09:11 UTC · resolved
    We identified an outbound networking issue affecting a subset of QStash server instances in the EU region between 2026-06-19 09:11 UTC and 2026-06-19 09:45 UTC. During this period, some requests dispatched by QStash may have failed. The issue has been resolved, and QStash is currently operating normally. We will publish a postmortem with additional details as soon as it is available. Update: We identified that one QStash server had been assigned an outbound IP address outside of the configured QStash IP range. This remained the case until 2026-06-19 11:24 UTC. Endpoints that restrict access based on QStash outbound IP allowlists may have rejected requests from this server during this period.
  2. 13:52 UTC · postmortem
    ## 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.
PostmortemSource
Jun 4, 20263h 59mSEV 2
Fly.io - Upstash Vector service disruption on IAD regionSev 2 from the incident title (no components listed)
3 updates
  1. 10:10 UTC · investigating
    We are currently experiencing a service disruption affecting Upstash Vector in the IAD region. Initial investigation indicates that the issue is related to a Fly.io networking/routing problem impacting connectivity in the region. The Fly.io team is actively investigating the underlying cause. We will continue to monitor the situation and provide updates as more information becomes available.
  2. 12:56 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  3. 14:09 UTC · resolved
    This incident has been resolved.
Source
May 29, 202611h 33mSEV 2
Intermittent slowness in Vector US-EAST-1 regionSev 2 because AWS - US-EAST-1 had degraded performanceAWS - US-EAST-1 +1
3 updates
  1. 20:18 UTC · investigating
    Some Upstash Vector indexes in the US-EAST-1 region may be experiencing intermittent slowness. Initial investigation indicates this may be related to memory pressure on the affected servers. Our team is actively investigating the root cause and working to restore normal performance. We will provide updates as soon as more information is available.
  2. 23:44 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  3. 07:51 UTC · resolved
    The issue affecting some Upstash Vector indexes in the US-EAST-1 region has been resolved. Our team investigated the incident and identified the conditions that were contributing to elevated memory pressure on the affected servers. We mitigated those conditions by reducing memory utilization on the impacted nodes, rebalancing affected workloads where needed, and increasing available headroom capacity across the region. All affected indexes should now be operating normally, and based on the mitigations applied, we do not expect this issue to recur. We apologize for any inconvenience this may have caused.
Source
May 22, 202632mSEV 2
New Database Creation Failing Due to Upstream Provider IssueSev 2 because N. Virginia, USA (us-east-1) had degraded performanceN. Virginia, USA (us-east-1) +31
3 updates
  1. 23:27 UTC · investigating
    New database provisioning is currently failing due to an ongoing upstream provider issue affecting DNS. Existing databases and connections are unaffected — only the creation flow is impacted. We're monitoring the situation and will update once the upstream issue is resolved.
  2. 23:48 UTC · monitoring
    Upstream issue resolved — new database creation is working again. We're monitoring to confirm full recovery.
  3. 00:00 UTC · resolved
    This incident has been resolved.
Source
May 14, 20261h 44mSEV 1
Upstash Redis – intermittent connection issues in some regionsSev 1 because N. Virginia, USA (us-east-1) had a partial outageN. Virginia, USA (us-east-1) +7
4 updates
  1. 15:47 UTC · monitoring
    We identified intermittent connection issues affecting some regions. Fix is being deployed. We'll update the list of affected regions shortly.
  2. 15:49 UTC · identified
    The issue has been identified and a fix is being implemented.
  3. 16:00 UTC · monitoring
    A fix has been implemented and we are monitoring.
  4. 17:31 UTC · resolved
    Earlier today, unexpected load on our proxies caused intermittent connection issues for Upstash Redis in the following regions: us-east-1, us-west-1, ap-southeast-2, and ap-south-1. During this period, some clients may have seen connection timeouts or elevated error rates when reaching their databases. Our team identified the issue quickly and applied workarounds to relieve pressure on the affected proxies. Connection health has since been restored and we've been monitoring the regions to confirm everything is stable. All systems are now operating normally. We appreciate your patience and apologize for any disruption this may have caused.
Source
May 12, 20263h 59mSEV 1
Fly.io Upstash Redis Service DistruptionSev 1 because the provider reported data loss or exposure
5 updates
  1. 09:49 UTC · investigating
    Some regions are experiencing connectivity issues due to an ongoing network problem. We are currently investigating
  2. 10:50 UTC · identified
    The issue has been identified and the fix is being implemented.
  3. 12:05 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  4. 13:48 UTC · resolved
    This incident has been resolved.
  5. 12:43 UTC · postmortem
    On May 12th and 13th at various times, a subset of Upstash Redis instances on [Fly.io](http://Fly.io) experienced intermittent hangs and elevated error rates. The Redis process would stall inside a logging syscall — alive but not making progress — which made the issue hard to spot from our usual telemetry. After investigating with Fly's team, we identified the root cause as a bad interaction between a recent guest kernel update on Fly's newer machines and an upstream Cloud Hypervisor bug \([cloud-hypervisor#7672](https://github.com/cloud-hypervisor/cloud-hypervisor/issues/7672)\) affecting log writes from inside the VM. We mitigated by disabling the affected logging paths, and Fly has since rolled out a hypervisor-side patch, fully resolving the issue. No data was lost. Sorry for the disruption.
PostmortemSource
May 11, 20263h 17mSEV 1
Fly.io Upstash Redis service distruption (FRA region)Sev 1 because the provider reported data loss or exposure
5 updates
  1. 15:05 UTC · investigating
    Some databases may experience increased latency or timeouts in Fly.io’s FRA region.
  2. 15:07 UTC · investigating
    We are continuing to investigate the issue.
  3. 17:19 UTC · investigating
    We are working with Fly team to investigate the root cause.
  4. 18:22 UTC · resolved
    The incident has been resolved. We are working with Fly team on RCA.
  5. 12:49 UTC · postmortem
    On May 12th and 13th at various times, a subset of Upstash Redis instances on [Fly.io](http://Fly.io) experienced intermittent hangs and elevated error rates. The Redis process would stall inside a logging syscall — alive but not making progress — which made the issue hard to spot from our usual telemetry. After investigating with Fly's team, we identified the root cause as a bad interaction between a recent guest kernel update on Fly's newer machines and an upstream Cloud Hypervisor bug \([cloud-hypervisor#7672](https://github.com/cloud-hypervisor/cloud-hypervisor/issues/7672)\) affecting log writes from inside the VM. We mitigated by disabling the affected logging paths, and Fly has since rolled out a hypervisor-side patch, fully resolving the issue. No data was lost. Sorry for the disruption.
PostmortemSource
May 8, 202622mSEV 1
QStash US Region Service DisruptionSev 1 because US-EAST-1 had a major outageUS-EAST-1 +1
5 updates
  1. 09:46 UTC · investigating
    We are currently investigating the issue.
  2. 09:46 UTC · investigating
    We are continuing to investigate this issue.
  3. 10:06 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  4. 10:08 UTC · resolved
    This incident has been resolved, we will publish RCA soon.
  5. 08:25 UTC · postmortem
    **Root Cause Analysis** On **April 24**, we deployed a more optimized scheduler implementation in the **US East \(N. Virginia\)** region. On **May 8**, a user who had active schedules deleted their account. Under normal behavior, scheduled tasks associated with a deleted account should wake up, detect that the account no longer exists, and exit after performing cleanup. Due to a bug introduced in the new scheduler implementation, this code path did not return early as intended. Execution continued and resulted in a nil pointer dereference. A second issue then amplified the impact. When a panic occurs in the scheduler, it is designed to be recovered, logged, and isolated so that the process remains healthy. Because of another bug in the panic recovery path, the panic was not properly caught, which caused the worker process handling the scheduled job to terminate. After that process exited, another worker picked up responsibility for delivering the same scheduled task. Since the same faulty execution path was still present, that worker also failed. This created a cascading failure pattern across workers attempting to process the affected schedules. **Resolution** We deployed two fixes: * Added the missing early return in the deleted-account cleanup path, preventing the nil pointer dereference. * Corrected the panic recovery logic so that future panics are safely recovered, logged, and reported without causing worker processes to terminate. With these changes in place, the affected execution path is now safe. Even if a future bug triggers a panic in this area, it will be isolated and reported rather than causing process-level failure.
PostmortemSource
May 5, 202617h 41mSEV 1
QStash US Region: Schedule DegradationSev 1 because the provider reported data loss or exposureUS-EAST-1 +1
6 updates
  1. 14:24 UTC · identified
    We are currently experiencing issues in the US region. - Duplicate Deliveries: During this period, some scheduled jobs may be executed twice. - Schedule Disruption: Schedules created between April 24, 2026 and May 2, 2026 are currently not running. Our team is actively working on a fix. Once the migration is complete, affected schedules will resume normal operation. We will provide updates as progress continues.
  2. 14:29 UTC · identified
    We are continuing to work on a fix for this issue.
  3. 15:44 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  4. 21:31 UTC · monitoring
    Main schedule functionality is back to normal. We are currently checking if previously created schedules are delivered as expected before marking the incident as resolved.
  5. 08:05 UTC · resolved
    This incident has been resolved.
  6. 08:55 UTC · postmortem
    # **Incident Postmortem: Scheduled Jobs Inconsistency in US Region** On May 1, 2026, we experienced an incident affecting a subset of schedules in the US region following a recent infrastructure update. The issue has been resolved, and all affected schedules have been restored. ## **Summary** As part of an ongoing scalability improvement, we recently updated scheduling infrastructure in the US region to a new architecture. During this transition, a legacy execution path remained in the codebase as a fallback mechanism. On May 1, a bug caused the system to revert to the legacy path. This resulted in inconsistent state between the old and new scheduling systems for some users. ## **Impact** The incident affected a limited number of users in the US region. **Most users were not affected**, and the vast majority of schedules continued operating normally throughout the incident. Users who did not update schedules during the transition window continued operating normally throughout the incident. **A subset of users who created, edited, paused, or deleted schedules between April 24 and May 1 may have experienced one or more of the following:** * Schedule updates not being reflected * Paused schedules becoming active again * Deleted schedules reappearing * Newly created schedules not executing as expected Schedules created after the transition may have stopped executing briefly before recovery. ## **Root Cause** During the transition, the new scheduling infrastructure became the source of truth for schedule state. Due to a bug, the system unexpectedly reverted traffic to the legacy scheduling path, which began accepting updates independently from the new system. This caused the two systems to diverge and resulted in inconsistent schedule state for affected users. ## **Resolution** After identifying the issue, we: 1. Restored the new scheduling system as the active source of truth 2. Reconciled data between the legacy and new systems 3. Updated missing schedule changes back into the new infrastructure 4. Performed conflict resolution to preserve user data and schedule continuity In some cases, schedules that had previously been paused or deleted were restored to avoid permanent data loss. ## **Preventive Measures** We are implementing several changes to prevent similar incidents: * Removing obsolete fallback execution paths after transitions complete * Adding automated safeguards and alerts for unexpected system fallback behavior * Improving consistency validation between systems * Expanding rollback and reconciliation testing We apologize for the disruption and appreciate everyone’s patience while we resolved the issue.
PostmortemSource
Apr 2, 20261h 08mSEV 2
Fly.io Upstash Redis – iad Region Elevated Latency and Temporary Read-Only StateSev 2 from the incident title (no components listed)
2 updates
  1. 18:45 UTC · identified
    Servers in the iad region experienced unexpected disk load, resulting in elevated latencies and a temporary read-only state. We are migrating replicas to new instances to mitigate the issue and expect to have it fully resolved shortly.
  2. 19:53 UTC · resolved
    Replication complete, incident resolved.
Source
Mar 27, 20260mSEV 2
Upstash Redis: GCP Global Connectivity ProblemsSev 2 from the incident title (no components listed)
1 update
  1. 15:30 UTC · resolved
    Due to a race condition in a process that attaches static IPs to nodes, some of the IPs in the dns were detached from the nodes, causing timeouts.
Source

Peers, 90 days

Compare
UpstashGrade A+100.00% up4 incidentsMTTR 0m~$22.25/moPlanetScaleGrade A100.00% up5 incidentsMTTR 26m$10/moCockroachDB CloudGrade B100.00% up5 incidentsMTTR 7h 00m–/moMongoDB AtlasGrade D100.00% up18 incidentsMTTR 2h 35m$56.94/moSupabaseGrade F100.00% up26 incidentsMTTR 2h 00m$25.25/mo

README badge

Upstash's live grade, for your README.

Upstash grade badge
[![upstash on downagain.dev](https://downagain.dev/badge/upstash.svg)](https://downagain.dev/p/upstash)