Supabase 中断历史

1. 2026年10月22日 UTC 18:03investigating

   在一些地区,使用木材排出物的客户可能缺少一些子集组件的路由日志。 我们放弃了修改 继续调查.

2. 2026年10月22日 UTC 18:22monitoring

   滚回使原木排出物恢复正常运作. 我们将监测是否继续运作.

3. 2026年10月22日 UTC 18:50resolved

   这个问题现已得到解决.

自动翻译自官方事件更新。

1. 2026年10月22日 UTC 17:01investigating

   我们注意到一些问题 请求来到我们的API网关。 我们正在调查.

2. 2026年10月22日 UTC 17:28identified

   我们已经确定这一问题与对后飞机的需求有关。 我们正在采取减缓措施,以扩大和管理这一需求.

3. 2026年10月22日 UTC 17:57monitoring

   缓解措施解决了需求激增的问题。 我们正在监测持续稳定.

4. 2026年10月22日 UTC 18:17monitoring

   我们将部署额外的缓解措施,以加强我们的后飞机。 我们将保持这一状态,并保持监测状态,直到所有缓解措施得到部署。 如果有任何可能影响到客户的变动,将公布最新情况.

5. 2026年10月23日 UTC 10:54monitoring

   我们将部署额外的缓解措施,以加强管理API。 如果有任何可能影响到客户的变动,将公布最新情况.

6. 2026年10月26日 UTC 10:16resolved

   这个问题已经解决,我们的反应时间已经恢复.

自动翻译自官方事件更新。

1. 2026年10月22日 UTC 11:29investigating

   我们正在调查高误差率和对多个区域管理API的反应时间。 依赖它的一些操作,例如创建新项目,可能失败或缓慢.

2. 2026年10月22日 UTC 11:32investigating

   我们正在调查高误差率和对多个区域管理API的反应时间。 依赖它的一些操作,例如创建新项目,可能失败或缓慢. 这也导致登录supabase.com超时.

3. 2026年10月22日 UTC 12:07monitoring

   已经采取了缓解措施。 出错率和延迟率已恢复正常水平。 持续稳定.

4. 2026年10月22日 UTC 13:42resolved

   误差率和延迟度在缓解后一直保持在正常水平。 这一事件现在已经得到解决.

自动翻译自官方事件更新。

1. 2026年10月22日 UTC 03:53monitoring

   我们发现欧盟地区自协调世界时10月21日23:00起在项目生命周期操作(创建、恢复、暂停等)中增加了出错率。 已实施缓解措施,出错率已降至正常水平。 我们正在监测局势并努力确定受影响的项目.

2. 2026年10月22日 UTC 09:15monitoring

   出错率保持在正常水平. 持续稳定.

3. 2026年10月22日 UTC 15:56resolved

   在缓解之后,误差率一直保持在正常水平上。 这一事件现在已经得到解决.

自动翻译自官方事件更新。

1. 2026年10月21日 UTC 15:36investigating

   我们正在调查一个影响项目生命周期运作的问题,例如所有区域的项目创建、收缩和恢复。 我们将在获得更多信息后提供进一步的最新资料.

2. 2026年10月21日 UTC 16:12monitoring

   已经采取了补救措施,我们观察到项目周期性工作失败的情况有所减少。 我们正在继续监测恢复情况,以确保正常行动保持稳定.

3. 2026年10月21日 UTC 16:51resolved

   影响项目生命周期运作的问题,包括项目的创建、贫困和恢复,已经得到解决。 我们看到在修复后项目周期性工作失败减少,并证实业务已恢复正常.

自动翻译自官方事件更新。

1. 2026年10月20日 UTC 21:59investigating

   东二区的一些工程被困在重启状态. 我们正在积极调查这一问题,并将在获得资料后提供更多的最新资料.

2. 2026年10月20日 UTC 23:06identified

   我们已经找出了这个问题的根源,并正在设法解决问题。 随着事态的发展,我们将继续提供最新情况.

3. 2026年10月20日 UTC 23:48identified

   我们正在为受影响的项目推出一个解决方案。 我们将随着推出的进展提供进一步的最新情况.

4. 2026年10月21日 UTC 01:38identified

   我们继续为受影响的项目提供解决办法。 我们将随着推出的进展提供进一步的最新情况.

5. 2026年10月21日 UTC 02:48identified

   我们继续为受影响的项目提供解决办法。 没有任何新项目受到影响,我们将随着推出的进展提供进一步的最新资料。 我们的下一次更新将在两个小时后完成.

6. 2026年10月21日 UTC 04:47monitoring

   修复工作已经全面展开。 项目不再处于重新启动状态。 我们将继续监测局势.

7. 2026年10月21日 UTC 05:39resolved

   所有受影响的项目均已确定。 我们没有看到这个问题再次发生,我们正在解决这一事件.

自动翻译自官方事件更新。

1. 2026年10月19日 UTC 17:13identified

   我们已经确定一个问题,即为一些客户创造支持票,我们在发展上有决心.

2. 2026年10月19日 UTC 17:36monitoring

   修补工作已经部署,出票工作恢复正常. 我们将继续进行监测.

3. 2026年10月19日 UTC 18:13resolved

   车票的创建一直正常. 我们正在解决这件事.

自动翻译自官方事件更新。

1. 2026年10月17日 UTC 06:27identified

   由于上游供应商持续停电,我们正在纠正APNE-1中的项目创建错误。 客户可能会看到在该区域创建或不支持一个项目时出现错误。 我们正在努力将交通重新导向未受影响的地区,并等待依赖我们的供应商提供最新情况.

2. 2026年10月17日 UTC 07:16monitoring

   我们的上游伙伴确认这个问题已经解决。 我们正在努力恢复项目创建流量返回该地区,并监测东北-1区的全面恢复情况.

3. 2026年10月17日 UTC 07:49resolved

   服务已完全恢复,东北一区已重新启用项目创建和不停车.

自动翻译自官方事件更新。

1. 2026年10月12日 UTC 22:59investigating

   我们正经历着与实时越来越紧密的关系,并正在积极调查.

2. 2026年10月13日 UTC 00:02monitoring

   我们查明了原因,并采取行动来纠正这些紧迫性高的问题。 我们将继续进行监测.

3. 2026年10月13日 UTC 06:38monitoring

   我们已采取预防性步骤来扩大我们的实时集群能力,并继续监测我们的系统稳定性,以全面恢复.

4. 2026年10月13日 UTC 13:49identified

   我们正看到实时延迟和不稳定性增加, 影响存在, 当我们继续就其余预防措施开展工作时,这种情况就会再次发生。 我们正在积极调查和采取步骤来减轻这种影响。 我们一旦掌握更多信息.

5. 2026年10月13日 UTC 17:34identified

   我们正在继续调查影响存在特征的实时延迟和不稳定增加的情况,这可能影响到加入率。 我们的小组正在积极开展缓解工作,一旦获得更多信息,我们将分享另一个最新情况.

6. 2026年10月13日 UTC 21:15identified

   并正在测试。 我们期望很快开始稳定受影响的集群。 我们将继续分享更多信息.

7. 2026年10月13日 UTC 23:27identified

   虽然某些地区仍存在一些问题, 我们正继续努力解决其余问题,并将在获得更多信息后分享进一步的最新情况.

8. 2026年10月14日 UTC 03:00monitoring

   我们稳定了受影响的用户,并改进了我们的实时基础设施。 我们将继续监测全面恢复情况.

9. 2026年10月14日 UTC 20:25resolved

   实时已完全恢复.

自动翻译自官方事件更新。

1. 2026年10月12日 UTC 19:49identified

   我们正在经历跨越边缘功能的显著退化,主要影响职能机构的部署和回收。 我们已查明了根源,目前正在努力解决问题.

2. 2026年10月12日 UTC 20:23identified

   我们现在看到边缘函数误差率降低. 我们已经查明了根源,正在设法解决问题.

3. 2026年10月12日 UTC 21:07identified

   边缘函数部署已恢复正常水平。 我们现在正在审查事故中失败的工人工作,包括可能受到影响的任何备份. 一旦确定这些工作,我们将重新排队,并在状态页面上分享更多细节. 如果你注意到一些不寻常的工作失败 请伸出援手.

4. 2026年10月13日 UTC 02:24monitoring

   边缘函数部署已恢复正常水平。 我们将继续监测全面恢复情况.

5. 2026年10月13日 UTC 18:24resolved

   边际职能部署保持稳定。 我们要结束这件事.

自动翻译自官方事件更新。

1. 2026年10月12日 UTC 19:39investigating

   日志摄入量目前受到阻碍。 日志可能延迟或无法获取 。 我们正在调查这个问题并努力恢复正常的功能。 一旦获得更多信息,我们将提供进一步的最新资料.

2. 2026年10月12日 UTC 20:09identified

   我们确定了影响记录摄入的问题。 日志可能延迟或无法获取 。 我们正在努力恢复正常功能.

3. 2026年10月12日 UTC 20:56identified

   我们正在对木材摄入问题进行补救,交通开始恢复。 我们正在继续努力实现全面恢复.

4. 2026年10月12日 UTC 22:17identified

   随着交通的继续恢复,我们继续寻找解决办法。 一旦获得更多信息,我们将提供进一步的最新资料.

5. 2026年10月13日 UTC 00:05identified

   随着交通的恢复,我们正在继续执行这一固定措施。 随着进展的继续,我们将提供进一步的最新情况.

6. 2026年10月13日 UTC 00:35monitoring

   修复工程已实施,系统已恢复正常运行. 日志摄入情况恢复正常,我们正在监测稳定情况.

7. 2026年10月13日 UTC 01:30resolved

   我们已经解决了记录摄入问题。 在这次事件发生期间,日志可能被延迟或无法提供. 日志摄入现已恢复正常运行.

自动翻译自官方事件更新。

1. 2026年10月21日 UTC 16:27resolved

   UTC2026年10月9日22:10至22:51之间,通过我们-东-1的"共享通宝"(Supavisor)所制造的新数据库连接约1%失败了"未能连接到数据库"超时出错. 故障的原因是我们的云端供应商发生了一起事件,它影响了可用区之间的网络交通。 Supabase项目数据库没有受到影响,事故发生前已经开通的连接仍然开放。 这个问题于协调世界时22:51解决. 在连接错误上重新测试的客户端会成功重新连接.

自动翻译自官方事件更新。

1. 2026年10月6日 UTC 15:23investigating

   我们看到试图升级到17.11.003. 我们正在调查.

2. 2026年10月6日 UTC 16:03identified

   我们已经将问题确定为升级问题。 为防止出现问题,我们暂停了在解决这一问题的同时更新项目的能力。 问题仅限于从更早的PG17版本升级到最新发行. 我们正在努力解决问题.

3. 2026年10月6日 UTC 16:37identified

   已经制定了解决办法,我们正在审查和执行进程.

4. 2026年10月6日 UTC 17:27monitoring

   修复工作已经实施。 升级操作已恢复 。 我们将监测稳定情况.

5. 2026年10月6日 UTC 18:18resolved

   我们已经推出一个解决这个问题的解决方案,并在仪表板上重新启用升级. 我们为不方便而道歉.

自动翻译自官方事件更新。

1. 2026年10月6日 UTC 15:23investigating

   我们看到试图升级到17.11.003. 我们正在调查.

2. 2026年10月6日 UTC 16:03identified

   我们已经将问题确定为升级问题。 为防止出现问题,我们暂停了在解决这一问题的同时更新项目的能力。 问题仅限于从更早的PG17版本升级到最新发行. 我们正在努力解决问题.

3. 2026年10月6日 UTC 16:37identified

   已经制定了解决办法,我们正在审查和执行进程.

4. 2026年10月6日 UTC 17:27monitoring

   修复工作已经实施。 升级操作已恢复 。 我们将监测稳定情况.

5. 2026年10月6日 UTC 18:18resolved

   我们已经推出一个解决这个问题的解决方案,并在仪表板上重新启用升级. 我们为不方便而道歉.

自动翻译自官方事件更新。

1. 2026年10月6日 UTC 07:53investigating

   我们正在调查项目更新流量中的错误增加的情况,包括多个区域的创建、缺乏/不支持和升级.

2. 2026年10月6日 UTC 08:10investigating

   我们正在继续调查这一问题.

3. 2026年10月6日 UTC 09:11resolved

   这个问题已经解决,我们的出错率已经恢复正常。 在这一事件期间,用户将观察到项目业务和仪表板功能在多个业务中出现未经授权的5xx故障。 此后我们推出了一个固定装置,恢复了所有功能.

4. 2026年10月6日 UTC 09:11monitoring

   我们已查明一个推出项目,造成管理上受抚养人服务出现错误增加,导致项目运行失败和多种功能的FGA认证出错。 我们已经执行一个固定和观察恢复。 我们的小组正在继续监测是否得到充分解决.

自动翻译自官方事件更新。

1. 2026年10月6日 UTC 07:53investigating

   我们正在调查项目更新流量中的错误增加的情况,包括多个区域的创建、缺乏/不支持和升级.

2. 2026年10月6日 UTC 07:55investigating

   我们正在继续调查这一问题.

3. 2026年10月6日 UTC 08:13monitoring

   我们已查明一个推出项目,造成管理上受抚养人服务出现错误增加,导致项目运行失败和多种功能的FGA认证出错。 我们已经执行一个固定和观察恢复。 我们的小组正在继续监测是否得到充分解决.

4. 2026年10月6日 UTC 09:03resolved

   这个问题已经解决,我们的出错率已经恢复正常。 在这一事件期间,用户将观察到项目业务和仪表板功能在多个业务中出现未经授权的5xx故障。 此后我们推出了一个固定装置,恢复了所有功能.

自动翻译自官方事件更新。

1. 2026年9月29日 UTC 16:26identified

   我们发现一个问题,在暴涨的交通流量造成高峰期间,美国东部的客户的延迟度增加。 这一点在EDT工作时间大约为下午和下午3点左右时分期间最为明显. 我们正在积极寻找解决办法。 我们将随着修正的实施提供最新情况.

2. 2026年9月29日 UTC 17:55identified

   我们正在继续努力解决这一暂时性问题,据观察,这一问题影响到美国东部连接Supabase项目的客户。 这些客户端可能包括位于该地理区域的服务器和无服务器功能,而不论项目所在区域.

3. 2026年9月29日 UTC 21:35identified

   今天早些时候对该问题采取了缓解措施,但我们没有足够的证据可以得出结论,即缓解措施导致美国东部这一延迟问题有所改善。 我们把这个问题与一项具体的《行动纲领》联系在一起,我们正继续与我们的网络伙伴合作,以最终解决这一问题。 我们将在4小时内提供另一个最新情况,如果不是在此之前。 我们感谢你的耐心.

4. 2026年9月30日 UTC 02:14identified

   我们正在与我们的网络伙伴合作,寻求永久解决办法。 虽然我们没有估计的解决时间,但我们将在此分享最新消息.

5. 2026年9月30日 UTC 14:54identified

   我们正在继续与我们的网络伙伴进行协调,以提出一个永久的决议。 我们一有消息就会提供.

6. 2026年9月30日 UTC 21:26identified

   我们看到一些改善的迹象,并正继续与我们的网络伙伴一起为找到解决办法而努力。 一旦获得更多信息,我们将提供另一个最新情况.

7. 2026年10月1日 UTC 20:23identified

   我们的网络伙伴已在美国东部有问题的《行动纲领》中缓解了暂时性问题,此后我们看到整个区域的高度长期性率有了显著提高。 我们正在继续与这些伙伴合作,以孤立造成拖延的任何其他根源并改进我们整个区域网络基础设施的可靠性.

8. 2026年10月2日 UTC 21:06identified

   虽然我们看到高延迟率有了显著的改善,但我们注意到,一些用户仍在美国东部最忙碌的营业时间遇到问题。 我们继续与我们的网络伙伴合作,以孤立并解决任何长期存在的遗留根源。 我们认识到这是一个长期问题,并赞赏受影响客户的耐心。 我们将继续在此分享补充最新情况.

9. 2026年10月5日 UTC 18:45monitoring

   这一问题已经解决,我们的数据表明,以前受到影响的项目的用户恢复了活力。 我们期望这一局势得到解决,但将持续一段时间进行监测,直至充分解决这一事件.

10. 2026年10月6日 UTC 12:15resolved

    这一问题已经解决,我们的数据显示,以前受影响的用户已经恢复.

自动翻译自官方事件更新。

1. 2026年9月29日 UTC 16:26identified

   我们发现一个问题,在暴涨的交通流量造成高峰期间,美国东部的客户的延迟度增加。 这一点在EDT工作时间大约为下午和下午3点左右时分期间最为明显. 我们正在积极寻找解决办法。 我们将随着修正的实施提供最新情况.

2. 2026年9月29日 UTC 17:55identified

   我们正在继续努力解决这一暂时性问题,据观察,这一问题影响到美国东部连接Supabase项目的客户。 这些客户端可能包括位于该地理区域的服务器和无服务器功能,而不论项目所在区域.

3. 2026年9月29日 UTC 21:35identified

   今天早些时候对该问题采取了缓解措施,但我们没有足够的证据可以得出结论,即缓解措施导致美国东部这一延迟问题有所改善。 我们把这个问题与一项具体的《行动纲领》联系在一起,我们正继续与我们的网络伙伴合作,以最终解决这一问题。 我们将在4小时内提供另一个最新情况,如果不是在此之前。 我们感谢你的耐心.

4. 2026年9月30日 UTC 02:14identified

   我们正在与我们的网络伙伴合作,寻求永久解决办法。 虽然我们没有估计的解决时间,但我们将在此分享最新消息.

5. 2026年9月30日 UTC 15:03identified

   我们正在继续与我们的网络伙伴进行协调,以提出一个永久的决议。 我们一有消息就会提供.

6. 2026年9月30日 UTC 21:26identified

   我们看到一些改善的迹象,并正继续与我们的网络伙伴一起为找到解决办法而努力。 一旦获得更多信息,我们将提供另一个最新情况.

7. 2026年10月1日 UTC 20:23identified

   我们的网络伙伴已在美国东部有问题的《行动纲领》中缓解了暂时性问题,此后我们看到整个区域的高度长期性率有了显著提高。 我们正在继续与这些伙伴合作,以孤立造成拖延的任何其他根源并改进我们整个区域网络基础设施的可靠性.

8. 2026年10月2日 UTC 21:06identified

   虽然我们看到高延迟率有了显著的改善,但我们注意到,一些用户仍在美国东部最忙碌的营业时间遇到问题。 我们继续与我们的网络伙伴合作,以孤立并解决任何长期存在的遗留根源。 我们认识到这是一个长期问题,并赞赏受影响客户的耐心。 我们将继续在此分享补充最新情况.

9. 2026年10月5日 UTC 18:45monitoring

   这一问题已经解决,我们的数据表明,以前受到影响的项目的用户恢复了活力。 我们期望这一局势得到解决,但将持续一段时间进行监测,直至充分解决这一事件.

10. 2026年10月6日 UTC 12:15resolved

    这一问题已经解决,我们的数据显示,以前受影响的用户已经恢复.

自动翻译自官方事件更新。

1. 2026年9月28日 UTC 13:47investigating

   日志摄入出现一些延迟。 摄取量会由客户重审.

2. 2026年9月28日 UTC 13:52identified

   日志摄入问题是比例差距的结果。 相关资源已经扩大,摄入量正在恢复.

3. 2026年9月28日 UTC 14:00monitoring

   日志摄入恢复了 我们正在监测持续稳定.

4. 2026年9月28日 UTC 14:36resolved

   日志摄入正常.

自动翻译自官方事件更新。

1. 2026年9月28日 UTC 13:47investigating

   日志摄入出现一些延迟。 摄取量会由客户重审.

2. 2026年9月28日 UTC 13:52identified

   日志摄入问题是比例差距的结果。 相关资源已经扩大,摄入量正在恢复.

3. 2026年9月28日 UTC 14:00monitoring

   日志摄入恢复了 我们正在监测持续稳定.

4. 2026年9月28日 UTC 14:36resolved

   日志摄入正常.

自动翻译自官方事件更新。