51 incidente Knak înregistrate începând din ianuarie 2018, cu actualizări oficiale, componente afectate, durată și informații despre rezolvare.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
The issue has been identified and a fix is being implemented.
We are continuing to work on a fix for this issue.
A Claude outage is degrading Knak AI's performance. We are monitoring the provider's status updates.
This incident has been resolved.
A fix has been implemented and we are monitoring
This incident has been resolved
We are currently investigating the issue
The issue has been identified
The issue has been identified and a fix has been deployed and we are currently monitoring
This incident has been resolved.
We are currently investigating.
The issue has been identified and we are implementing the fix.
A fix has been implemented and we are now monitoring
We are continuing to monitor for any further issues.
This incident has now been resolved. Assets synced between 9:00 AM and 10:04 AM EST will have to be resynced.
We are currently investigating an issue with global UTM input field not visible
The issue has been identified and we are working to release a fix
A fix has been implemented and we are monitoring the release of the fix
This incident has been resolved.
We are currently investigating the issue.
A fix has been applied and we are monitoring
We are currently investigating an issue with the Knak tracking pixel
A fix has been implemented and we are monitoring
This incident has been resolved.
### **Quick Summary** Between **January 9th and January 19th**, Knak experienced an issue with our analytics tracking pixel affecting data collection for a subset of clients. This was caused by a system upgrade intended to improve performance and remove rate limits. While the upgrade successfully improved traffic capacity, it introduced a data formatting error that prevented tracking data from being saved to our database. **The tracking pixel itself continued to function for end-users \(email recipients\), ensuring no broken images or errors were visible.** We have since rolled back the change, restored partial data, and implemented new safeguards to prevent this from recurring. ### **What This Means** For clients who have the Knak Tracking Pixel enabled, **we were unable to collect performance data between January 9th at 10:32 AM EST and January 19th at 5:26 PM EST.** While your emails were delivered successfully and the pixel image loaded correctly for your recipients, the "open" event data was not stored in our database. Consequently, analytics reports for campaigns sent or active during this specific window will not reflect the actual open rates or engagement metrics. This did not impact downstream reporting from marketing automation platforms or any performance data Knak collects from those systems. This issue only affected assets with the “Knak Tracking Pixel” enabled in settings. No action is required from Knak clients. ### **Root Cause** In December, we identified that our previous tracking proxy service had a strict request limit that throttled data collection during high-volume campaigns. To support higher traffic and remove these limits, we migrated to a new, more scalable proxy service on January 9th. The root cause of the incident was a data formatting mismatch between this new proxy service and our data processing software. * **The Mismatch:** The new service delivered tracking information \(such as timestamps\) in a different structural location than the previous service. * **The Failure:** When our processing software could not locate the timestamps in the expected place, it defaulted the values to the text string "Unknown." * **The Data Loss:** Our analytics database is designed to store timestamps strictly as numbers. When the system attempted to save the text "Unknown" into a number-only field, the database rejected the incoming data batches. This resulted in a scenario where the tracking pixel successfully loaded for the end-user \(the email recipient saw no errors\), but the data was silently rejected by our database backend. ### **Timeline** _All times are in Eastern Standard Time \(EST\)_ * **January 9, 10:32 AM:** The infrastructure upgrade to the new proxy service is deployed to remove rate limits. Data collection stops due to the formatting mismatch described above. * **January 19, 3:38 PM:** Our team identifies a gap in success logs for tracking jobs and immediately begins an investigation. * **January 19, 4:06 PM:** The engineering team confirms that while requests are hitting the server, data is not persisting into the analytics database. * **January 19, 5:26 PM:** **Service Restored.** We roll back the infrastructure to the previous proxy service. Valid data collection resumes immediately for all new requests. * **January 20, 12:30 PM:** The team identifies the specific database rejection error \(String vs. Integer type mismatch\). * **January 20, 1:54 PM:** A code fix is deployed to ensure timestamps can never default to an invalid format, preventing this specific failure mode in the future. * **January 20, 2:01 PM:** Engineering began investigating methods to recover and backfill any partial data available from the outage window. ### **Learnings & Actions Taken** To prevent a recurrence, Knak is implementing the following changes to our engineering and monitoring protocols: 1. **Eliminating Silent Failures:** We will update our code to prioritize error visibility. While the tracking pixel will always load for the user \(to ensure the recipient experience is never impacted\), our backend systems will soon aggressively log and flag when default values are used instead of real data. 2. **Volume-Based Alerting:** We are implementing new alerts that trigger specifically when data flow into our database drops unexpectedly. Previously, our alerts focused on _server errors_ \(crashes\). Since the server was technically "running" \(just processing bad data\), no alarm sounded. The new alerts will focus on _data throughput_. 3. **Strict Data Validation:** We have added stricter validation logic to our ingestion pipeline to ensure that data types \(like timestamps\) are verified before they reach the database, preventing a single formatting error from rejecting a batch of data. 4. **Partial Data Restoration**: We have now began the process to partially restore some data between January 19th and January 20th
We are currently investigating an issue of PDFs not being able to download
This incident is resolved PDFs can be downloaded again
We are currently investigating this issue.
We have been experiencing a temporary outage due to the ongoing AWS outage https://health.aws.amazon.com/health/status. We are currently stable but are closely monitoring the situation.
This incident has been resolved.
The issue has been identified and a fix is being implemented.
We are continuing to work on a fix for this issue.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
### Timeline On October 8th, at 1:27PM EST we deployed a package upgrade to our backup rendering service which is responsible for generating previews of pdfs and pngs. At 2:06PM EST we routed our production traffic to our backup rendering service. During which time it was monitored noting that the service was succeeding users were able to download pdfs and pngs At 3:01PM EST Knak Engineers were informed that the pdfs and pngs being download were blank pdfs and pngs. At 3:18PM EST Knak Engineers reverted the traffic back to the primary rendering service, which they then confirmed that pdfs and pngs were correctly downloading ### Root Cause An underlying package that our rendering service relies on has implemented a breaking change. It was believed that the package upgrade followed standard semantic versioning which would mean that this was minor change which would not impact production, it was later discovered it does not follow semantic versioning. This was not noticed in our non production environments as functionally from an integration standpoint our rendering service was taking in code and rendering a pdf/png. ### Action Taken * We have rolled back the change and went back to testing the package upgrade * We have documented how to manually end to end test our rendering service * We are working on implementing a fully automated end to end test for our application/rendering service
The issue is believed to be caused by a potential sub-processor outage.
The issue has been resolved and is being monitored.
This incident has been resolved.
On June 12, 2025 \(EDT\), our AI-powered features experienced a temporary service disruption. Our team immediately identified the cause as an outage with one of our sub-processors and monitored the situation until service was restored by the external provider. **Root Cause:** The issue was caused by a temporary service outage on the Google Cloud Vertex AI platform, an external service that our AI features depend on to function.
This incident has been resolved.
On April 3rd at 7:26 AM EDT, our application experienced an incident resulting in unresponsiveness and the inability to serve requests. Upon immediate awareness, remediation efforts were initiated, and a temporary fix was implemented by 8:25 AM EDT, at which time resolution of the underlying cause was believed to be achieved. On April 4th at 8:48 AM EDT, the application again became unresponsive. A swift response facilitated the deployment of another temporary fix by 9:03 AM EDT on April 4th. Subsequent investigation revealed the root cause to be the unintended accumulation of temporary server operating logs, leading to disk space exhaustion on the application server. A permanent fix has since been implemented to prevent further log accumulation, and no additional space consumption has been observed. No action is required from our customers regarding this incident. **Root Cause:** During runtime our logging system was failing to send logs to our external logging tools this prompted the server to fail back to logging within the server, the logging directory was ephemeral storage so a new deployment would temporarily fix the issue. It was not until April 3rd at 7:26AM EDT that our temporary storage had completely filled causing the server to not have any disk swap space; rendering the server to be unable to respond to request **Actions:** 1. We have since fixed the issue with our logging so that we are not failing back to logging on the server 2. We have also added strict alerting on our temporary storage on our server to ensure that we are alerted if we are soon going to run out of space
We are currently investigating this issue.
A fix has been implemented and we are monitoring the results.
We are continuing to monitor for any further issues.
This incident has been resolved.
On April 3rd at 7:26 AM EDT, our application experienced an incident resulting in unresponsiveness and the inability to serve requests. Upon immediate awareness, remediation efforts were initiated, and a temporary fix was implemented by 8:25 AM EDT, at which time resolution of the underlying cause was believed to be achieved. On April 4th at 8:48 AM EDT, the application again became unresponsive. A swift response facilitated the deployment of another temporary fix by 9:03 AM EDT on April 4th. Subsequent investigation revealed the root cause to be the unintended accumulation of temporary server operating logs, leading to disk space exhaustion on the application server. A permanent fix has since been implemented to prevent further log accumulation, and no additional space consumption has been observed. No action is required from our customers regarding this incident. **Root Cause:** During runtime our logging system was failing to send logs to our external logging tools this prompted the server to fail back to logging within the server, the logging directory was ephemeral storage so a new deployment would temporarily fix the issue. It was not until April 3rd at 7:26AM EDT that our temporary storage had completely filled causing the server to not have any disk swap space; rendering the server to be unable to respond to request **Actions:** 1. We have since fixed the issue with our logging so that we are not failing back to logging on the server 2. We have also added strict alerting on our temporary storage on our server to ensure that we are alerted if we are soon going to run out of space
We are currently investigating this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
At 10:10AM EDT today, a release of Knak was published which caused issues with custom column sizing. As soon as Knak was made aware of the issue, we rolled back the release (at 11:20AM EDT). Any email, landing page, theme, or module opened during that time (10:10AM-11:20AM EDT) that had custom column sizing would have been affected. For emails and landing pages opened during that time that have issues with column sizing, the recommendation is to use the version history feature in the info tab (https://help.knak.io/en/articles/4449817-email-landing-page-version-updates) to roll the asset back to a version prior to 10:10AM EDT this morning. For themes and modules that are affected, please communicate with support so that they can roll those versions back in your instance.
The issue has been identified and a fix is being implemented. A workaround for the moment is to disable uBlock Origin for the Knak site specifically
The incompatibility with uBlock Origin in today's release has been resolved. Note that the issue was only affecting users that were using privacy blockers such as uBlock Origin.
The application was unavailable from 8:16AM to 9:00AM.
**Root Cause:** During the last application build, a failure transpired while attempting to write the JavaScript assets to the S3 bucket essential for our CDN functionality. Consequently, when the deployment took place, our main application was referencing assets that were absent. **Actions:** 1. We are reordering our build sequence to ensure that the copying of assets to S3 transpires prior to the push to ECR, thereby implementing a fail-safe mechanism. 2. We are enhancing our rollback procedure to simplify its execution for all parties, enabling headless operation. 3. We will be reviewing and addressing observability gaps for builds, and release monitoring.
Images edited in the builder before December 12th, 2022 used a service that would generate a URL based on the transformations applied to the images. Going forward, any new images edited will not use this service. As part of our security reviews, it was found that we needed to add trust hosts in order to validate that requests were being serviced from the right DNS name(s). Unfortunately, in tightening the restrictions and creating an allow list that included enterprise.knak.io, adding the edited-images.knak.io was missed and requests to this legacy service started failing.
* We will be formalizing and streamlining our incident response process since some of the initial response to the issue could have been more prompt. Formalizing the process also makes it so that we don't skip steps \(i.e. putting up a status page for the partial outage\) * We are making changes to our observability platform to ensure that these types of issues are addressed in a more timely manner before customers bring it up.
We are currently investigating an issue where users are unable to save their emails and landing pages in Knak. This is in relation to an outage with AWS on us-east-1. https://health.aws.amazon.com/health/status
The application is working as expected again and we are monitoring to ensure no other issues surface.
This incident has been resolved.