Smarty Outage History

This incident has been resolved.

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.

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.

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

This incident has been resolved.

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.

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.

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.

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.

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

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.

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.

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

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.