Smarty Outage History
Smarty is up right nowPingoru has recorded 50 incidents for Smarty: 11 in the last 12 months and 3 in the last 90 days.
Show as a table
| Month | Incidents | Hours with an open incident |
|---|---|---|
| April 2026 | 1 | 0 of 720 (0%) |
| May 2026 | 0 | 0 of 744 (0%) |
| June 2026 | 1 | 0 of 720 (0%) |
| July 2026 | 1 | 2 of 744 (0%) |
| August 2026 | 1 | 20 of 744 (3%) |
| September 2026 | 2 | 3 of 720 (0%) |
| October 2026 | 0 | 0 of 510 (0%) |
Incidents, newest first
Notice September 26, 2026 Monitoring – Intermittent Service Availability 57m US East 1, US East 1, US East 1, US East 1 and 34 more
Started Sep 26, 2026, 03:51 PM UTC· resolved Sep 26, 2026, 04:49 PM UTC
- monitoring Sep 26, 2026, 03:51 PM UTC
At 15:23 UTC we began investigating reports of some services being intermittently unavailable. Service has since been fully restored and all systems are operating normally. We are monitoring closely and continuing to investigate the root cause.
- resolved Sep 26, 2026, 04:49 PM UTC
The incident has been resolved. We are conducting a more thorough investigation to discover the root cause.
- postmortem Sep 28, 2026, 07:03 PM UTC
**Post-incident summary** On September 26, 2026, from 15:28 to 15:39 UTC, requests to our APIs failed sporadically. A large portion of requests were refused outright for several minutes. A few regions briefly recovered partial capacity at 15:30 UTC. What happened: a server in an internal system that our load balancers depend upon ran out of disk space but didn’t fail over properly to a peer node. When that system stopped answering, various load balancers across the regions began restarting automatically. Our engineers moved the affected system to a healthy server at 15:37 UTC, and service was fully restored by 15:39 UTC. What we are doing: we have increased disk capacity and changed log retention on the affected system so it cannot run out of space this way again. We are also changing how our load balancers behave when that system is unavailable, so they keep serving traffic instead of shutting down, and we are adding alerting that would have caught the problem before it affected you.
Critical September 10, 2026 Account Management Portal - Login 2h 23m Account Management Portal
Started Sep 10, 2026, 08:14 PM UTC· resolved Sep 10, 2026, 10:37 PM UTC
- investigating Sep 10, 2026, 08:14 PM UTC
We are currently investigating Login issues and hope to have a resolution shortly. Product APIs are unaffected and fully operational.
- investigating Sep 10, 2026, 08:16 PM UTC
We are continuing to investigate this issue.
- investigating Sep 10, 2026, 08:18 PM UTC
We are continuing to investigate this issue.
- resolved Sep 10, 2026, 10:37 PM UTC
The issue has been resolved. The only service that was affected was the Account Management Portal. This incident did NOT affect production traffic to our APIs (address verification, autocomplete, geocoding, etc.)
Notice August 19, 2026 US Street API returning 503 response codes 20h 24m US East 1, US West 1, US Central 1, US South 1
Started Aug 19, 2026, 12:49 AM UTC· resolved Aug 19, 2026, 09:13 PM UTC
- investigating Aug 19, 2026, 12:49 AM UTC
A small number of intermittent 503 Errors for US Street [Address] API are affecting a few requests. This is currently being investigated.
- resolved Aug 19, 2026, 09:13 PM UTC
This incident has been resolved.
Notice June 3, 2026 Scheduled TLS Certificate Update — Let's Encrypt Intermediate Rotation –
Started Jun 03, 2026, 08:17 PM UTC· resolved Jun 03, 2026, 08:17 PM UTC
- resolved Jun 03, 2026, 08:17 PM UTC
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.
Notice April 17, 2026 API Certificate Chain Updated — Older Runtimes May Need Trust Store Update –
Started Apr 17, 2026, 01:00 AM UTC· resolved Apr 17, 2026, 01:00 AM UTC
- resolved Apr 24, 2026, 05:39 PM UTC
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.
Notice March 16, 2026 US [Address] Autocomplete Pro API went offline briefly in one datacenter – US East 1
Started Mar 16, 2026, 10:35 PM UTC· resolved Mar 16, 2026, 10:35 PM UTC
- resolved Mar 16, 2026, 10:35 PM UTC
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.
Notice March 6, 2026 Intermittent 503 Errors for US Street [Address] API 3d 21h US East 1, US West 1, US Central 1, US South 1
Started Mar 06, 2026, 05:59 PM UTC· resolved Mar 10, 2026, 03:58 PM UTC
- investigating Mar 06, 2026, 05:59 PM UTC
We are currently investigating an increase in 503 Service Unavailable errors. We will provide an update as soon as more information is available.
- monitoring Mar 06, 2026, 09:16 PM UTC
The issue has been identified and we are currently monitoring overall system health.
- resolved Mar 10, 2026, 03:58 PM UTC
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.
Notice February 18, 2026 US Extract API briefly returned incorrect HTTP status code 1h 19m
Started Feb 18, 2026, 12:40 AM UTC· resolved Feb 18, 2026, 02:00 AM UTC
- resolved Feb 18, 2026, 12:40 AM UTC
Around 19:15 UTC an incorrect configuration was deploy to our US Extract API service. The problem was quickly detected and reverted.
Notice November 27, 2025 Intermittent HTTP 5xx Errors Returned by US Street API and US Zip Code API 4d 16h
Started Nov 27, 2025, 12:32 AM UTC· resolved Dec 01, 2025, 05:07 PM UTC
- monitoring Nov 27, 2025, 12:32 AM UTC
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.
- resolved Dec 01, 2025, 05:07 PM UTC
This incident has been resolved.
Notice July 18, 2025 Intermittent failures with Google login (oauth) integration –
Started Jul 18, 2025, 04:25 PM UTC· resolved Jul 18, 2025, 04:25 PM UTC
- resolved Jul 18, 2025, 04:25 PM UTC
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.
Notice May 15, 2025 Account page not listing API keys –
Started May 15, 2025, 02:00 PM UTC· resolved May 15, 2025, 02:00 PM UTC
- resolved May 15, 2025, 02:32 PM UTC
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.
Minor March 18, 2025 Misbehaving servers resulted in some 503 responses –
Started Mar 18, 2025, 08:01 PM UTC· resolved Mar 18, 2025, 08:01 PM UTC
- resolved Mar 18, 2025, 10:11 PM UTC
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.
Minor February 26, 2025 Intermittent HTTP 500 codes returned by US Enrichment API 35m
Started Feb 26, 2025, 05:00 PM UTC· resolved Feb 26, 2025, 05:35 PM UTC
- resolved Feb 26, 2025, 08:31 PM UTC
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.
Notice February 7, 2025 Network outage in one facility 30m
Started Feb 07, 2025, 09:15 PM UTC· resolved Feb 07, 2025, 09:45 PM UTC
- resolved Feb 07, 2025, 09:15 PM UTC
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
Notice January 10, 2025 Intermittent HTTP 503 Errors – US East 1, US West 1, US Central 1, US South 1
Started Jan 10, 2025, 09:12 PM UTC· resolved Jan 10, 2025, 09:12 PM UTC
- resolved Jan 10, 2025, 09:12 PM UTC
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.
Notice December 30, 2024 Intermittent HTTP 503 Errors: – US East 1, US East 1, US West 1, US West 1 and 10 more
Started Dec 30, 2024, 10:32 PM UTC· resolved Dec 30, 2024, 10:32 PM UTC
- resolved Dec 30, 2024, 10:32 PM UTC
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.
Notice December 19, 2024 HTTP 299 response code –
Started Dec 19, 2024, 11:00 PM UTC· resolved Dec 19, 2024, 11:00 PM UTC
- resolved Dec 20, 2024, 04:11 PM UTC
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
Notice November 28, 2024 Single IP address caused some traffic to be null routed –
Started Nov 28, 2024, 05:00 PM UTC· resolved Nov 28, 2024, 05:00 PM UTC
- resolved Dec 09, 2024, 07:45 PM UTC
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.