Smarty 中断历史

1. 2026年9月26日 UTC 15:51monitoring

   在协调世界时15点23分,我们开始调查一些服务断断续续无法提供的报告。 服务现已完全恢复,所有系统都正常运行。 我们正在密切监测并继续调查其根源.

2. 2026年9月26日 UTC 16:49resolved

   此事已决. 我们正在进行更彻底的调查,以找出根源.

3. 2026年9月28日 UTC 19:03postmortem

   ** 事后事件摘要** 2026年9月26日,从协调世界时15:28到15:39,向我国API提出的要求零星失败. 大部分请求被断然拒绝几分钟。 少数地区在协调世界时15:30短暂恢复了部分能力. 我们的负载平衡器依赖于磁盘空间的耗尽, 但并没有对端节点发生故障。 当该系统停止回答时,各地区的各种负载平衡器开始自动重启。 我们的工程师在协调世界时15:37将受影响的系统移动到健康的服务器上,服务在协调世界时15:39完全恢复. 我们正在做的是:我们增加了磁盘容量,改变了在受影响的系统中的日志保留,因此它不能再次以这种方式耗出空间。 我们还在改变我们的负载平衡器在系统无法使用时的表现, 因此它们继续服务于交通而不是关闭, 我们正在增加警报, 这会在它影响你之前就已经抓住问题.

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

1. 2026年9月10日 UTC 20:14investigating

   我们目前正在调查登录问题,并希望能很快解决。 产品API不受影响并全面运行.

2. 2026年9月10日 UTC 20:18investigating

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

3. 2026年9月10日 UTC 22:37resolved

   这个问题已经得到解决。 唯一受到影响的服务是账户管理门户。 这一事件没有影响我们向API的生产流量(地址核查、自动完成、地理编码等)

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

1. 2026年8月19日 UTC 00:49investigating

   少数断断续续的503 Errors for US Street[Address] API正在影响少数请求. 目前正在对此进行调查.

2. 2026年8月19日 UTC 21:13resolved

   这一事件已经得到解决.

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

1. 2026年7月21日 UTC 22:30identified

   从UTC19:00开始,出乎意料的输入导致从美国街地址API返回503响应代码的请求比例很小. 决议目前正在通过之中,一旦完成,将在本网页上公布最新情况.

2. 2026年7月21日 UTC 22:33identified

   我们正在继续努力解决这个问题。

3. 2026年7月21日 UTC 22:56monitoring

   固定装置已经实施,正在向舰队发射。 我们正在监测结果.

4. 2026年7月21日 UTC 23:10monitoring

   推出完毕 我们正在继续监测.

5. 2026年7月22日 UTC 00:34resolved

   这一事件已经得到解决.

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

1. 2026年6月3日 UTC 20:17resolved

   SUMMARY We are rotating the Let's Encrypt intermediate certificates used to issue the TLS certificates that secure our services. Our certificates will continue to chain to the same trusted root — ISRG Root X1 — but through Let's Encrypt's new "Generation Y" intermediate hierarchy. For the vast majority of customers, no action is required. If your systems validate our certificates against the public root store — the default for virtually all browsers, operating systems, and HTTP client libraries — this change is completely transparent. The only customers who may be affected are those who pin a specific Let's Encrypt intermediate certificate. WHY WE'RE MAKING THIS CHANGE The intermediate certificates currently in our chain are approaching the end of their lifecycle, with the existing intermediate path expiring in approximately nine months. Rotating well ahead of that deadline guarantees uninterrupted certificate issuance and renewal with no disruption to your integrations. THE CHAIN OF TRUST A TLS certificate is never validated on its own. It is verified through a chain that links the connection back to a root certificate your device already trusts. Today, our certificates chain like this: Your connection → Smarty leaf certificate → Let's Encrypt intermediate → ISRG Root X1 After this update, they will chain like this: Your connection → Smarty leaf certificate → Let's Encrypt Generation Y intermediate (YR / YE) → ISRG Root YR / YE → ISRG Root X1 (via cross-sign) The destination is unchanged. Both the old and new paths terminate at ISRG Root X1, the RSA root that ships in every current major trust store. Let's Encrypt cross-signed its new Generation Y roots with the existing X1 and X2 roots specifically so that anything already trusting X1 continues to work without modification. The path is longer; the anchor of trust is identical.

1. 2026年4月24日 UTC 17:39resolved

   At 00:00 UTC on April 17, A scheduled certificate renewal updated the CA chain served by api.smartystreets.com. The change was made without advance notice to integrators, and the new chain is anchored by Sectigo roots (USERTrust ECC Certification Authority and USERTrust RSA Certification Authority) that are not present in some older trust stores. Clients on current operating systems, browsers, and runtimes continue to work without change. Connections may fail for systems that: - Use a custom or pinned TLS trust bundle that does not include USERTrust ECC Certification Authority. - Run Java 8 installations predating update 51 (mid-2015) or earlier Java versions — these do not ship USERTrust ECC Certification Authority in the default cacerts keystore. - Run other environments with outdated trust stores, including older Android devices, legacy embedded and IoT hardware, and air-gapped systems. To restore connectivity, affected systems should either update to a current runtime or add the Sectigo roots (USERTrust ECC Certification Authority and USERTrust RSA Certification Authority) to their trust store. Please reach out to support for assistance.

1. 2026年3月16日 UTC 22:35resolved

   Around 22:00 UTC the US [Address] Autocomplete Pro API service in one of our datacenters went offline due to a misconfiguration. The problem was quickly identified and rectified. All other datacenters were unaffected.

1. 2026年3月6日 UTC 17:59investigating

   We are currently investigating an increase in 503 Service Unavailable errors. We will provide an update as soon as more information is available.

2. 2026年3月6日 UTC 21:16monitoring

   The issue has been identified and we are currently monitoring overall system health.

3. 2026年3月10日 UTC 15:58resolved

   The issue has been resolved. A small number of nodes experienced large memory consumption which resulted in a few 503 errors being returned. This has been resolved and measures have been put in place to mitigate this in the future. Additional alerts and monitors have also been put in place.

1. 2026年2月18日 UTC 00:40resolved

   Around 19:15 UTC an incorrect configuration was deploy to our US Extract API service. The problem was quickly detected and reverted.

1. 2025年11月27日 UTC 00:32monitoring

   We've identified an issue affecting one of our redundant facilities. As a precaution, it has been taken out of active rotation while we investigate.

2. 2025年12月1日 UTC 17:07resolved

   This incident has been resolved.

1. 2025年10月30日 UTC 22:36monitoring

   During a routine data deployment, we noticed a brief spike in 5xx error responses. Systems have since stabilized, and we're investigating the root cause to confirm the issue is fully resolved and to prevent similar behavior in future deployments.

2. 2025年11月4日 UTC 15:35resolved

   This incident has been resolved.

1. 2025年7月18日 UTC 16:25resolved

   We have become aware that Google services have been exhibiting some intermittent failures. As a result, anyone using "Login with Google" to access their account dashboard on our website may also experience a failure to login. When Google is able to resolve the issues they are having, the login will continue to work as normal. In the meantime, if you have created a username and password, you should be able to use those to login.

1. 2025年5月15日 UTC 14:32resolved

   We discovered that the "API Keys" page in our Account dashboard web site was not able to retrieve the lists of keys from the backend service. This has now been fixed.

1. 2025年3月18日 UTC 22:11resolved

   Around 19:10 UTC, increased traffic exposed resource limitations caused by a previously implemented algorithm update, leading to issues on several servers hosting some of our services (US Street API, US Extract API) in one of our data centers due to insufficient RAM. To ensure stability and service reliability, the affected servers have been decommissioned and replaced with upgraded hardware.

1. 2025年2月26日 UTC 20:31resolved

   The US Enrichment API intermittently returned HTTP 500 codes in a single data center on 2025 February 26 around 17:00 UTC. The issue has been resolved as of 17:35 UTC.

1. 2025年2月7日 UTC 21:15resolved

   Around 18:00 UTC, one of our facilities experienced a network routing issue that lasted for about 30 minutes. The facility was removed from DNS rotation until the network issue had been resolved. If you have not yet read through our "Technical Requirements" and "Best Practices" documentation, this could be a good opportunity to become familiar with those important and helpful documents. - https://www.smarty.com/docs/cloud/requirements#retry - https://www.smarty.com/docs/cloud/best-practices

1. 2025年1月10日 UTC 21:12resolved

   From 01/08 12pm UTC to 01/09 9am UTC some requests to the US Street [Address] API instances experienced an intermittent issue with certain malformed addresses that caused some requests to not get a response, returning HTTP 503 errors to those requests. This affected a small number of requests and the error has since been resolved.

1. 2024年12月30日 UTC 22:32resolved

   During a regular upgrade of our control plane, several controller nodes became unresponsive. This resulted in various routing issues which were manifest by intermittent HTTP 503 errors visible in the HTTP response to some callers. Our monitoring systems alerted our Operations Engineering Team of the anomaly and, as a result, the affected cluster, located in our US Central region (Chicago), was immediately removed from production rotation. The affected cluster has been restored to full health by provisioning new cloud resources using our IaC (infrastructure as code) systems. Following this, the cluster was confirmed to be was healthy via our automated monitoring and was subsequently re-introduced into active rotation.

1. 2024年12月20日 UTC 16:11resolved

   On 2024 December 19, around 22-24:00 UTC, some users may have received the HTTP 299 code in response to requests from one of our loadbalancers. The reason for this response has been identified and remediated. We would like to take this opportunity to remind our users to familiarize themselves with our best practices. https://www.smarty.com/docs/cloud/best-practices

1. 2024年12月9日 UTC 19:45resolved

   Around 15:00 (3pm) UTC on 2024 November 28, a single IP address at one of our datacenters experienced a routing issue that caused some requests to be "null routed", which may have resulted in some clients experiencing 500 level errors during that time. This issue persisted until 17:00 (5pm) UTC on 2024 November 28, at which time our upstream provider resolved the issue. Our recommendation to clients to mitigate an issue such as this in the future is to maintain a pool of active TCP connections to the server nodes and to only send traffic over active, healthy TCP connections. Then a background "thread" (or programmatic equivalent) could attempt to connect to the suspect IPv4 address. Once that connection has determined to be healthy, regular traffic can be resumed over that TCP connection.