Cronologia delle interruzioni di Knak

1. 21 ottobre 2026 alle ore 13:28 UTCinvestigating

   I nostri team di Ingegneria e Sicurezza stanno rispondendo a PHP2SHELL, una vulnerabilità recentemente divulgata nel software web ampiamente utilizzato, compresi i componenti che Knak si basa su. Stiamo monitorando attivamente i nostri sistemi e applicando misure di protezione. La protezione dei dati viene prima. Se vediamo una minaccia che ha bisogno di ulteriore azione, possiamo prendere Knak offline temporaneamente, forse con poco preavviso. Sappiamo che qualsiasi disturbo influisce sulla capacità del vostro team di costruire e lanciare campagne. Ci scusiamo per l'inconveniente e pubblicheremo aggiornamenti sulla nostra pagina di stato in quanto diventano disponibili.

2. 21 ottobre 2026 alle ore 14:27 UTCinvestigating

   Stiamo facendo un'azione

3. 21 ottobre 2026 alle ore 14:28 UTCinvestigating

   Stiamo facendo un'azione.

4. 21 ottobre 2026 alle ore 15:12 UTCinvestigating

   Abbiamo applicato la patch e attualmente lo stanno testando prima di portare Knak indietro online. La nostra indagine preliminare non ha dimostrato che Knak sia stato compromesso. Ti faremo sapere non appena Knak sarà tornato.

5. 21 ottobre 2026 alle ore 15:32 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

6. 21 ottobre 2026 alle ore 15:45 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

7. 21 ottobre 2026 alle ore 16:03 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

8. 21 ottobre 2026 alle ore 19:05 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 16 luglio 2026 alle ore 19:17 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

2. 16 luglio 2026 alle ore 22:11 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 17 luglio 2026 alle ore 03:33 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 giugno 2026 alle ore 14:39 UTCidentified

   The issue has been identified and a fix is being implemented.

2. 23 giugno 2026 alle ore 14:40 UTCidentified

   We are continuing to work on a fix for this issue.

3. 23 giugno 2026 alle ore 14:42 UTCmonitoring

   A Claude outage is degrading Knak AI's performance. We are monitoring the provider's status updates.

4. 23 giugno 2026 alle ore 16:14 UTCresolved

   This incident has been resolved.

1. 8 maggio 2026 alle ore 13:26 UTCmonitoring

   A fix has been implemented and we are monitoring

2. 8 maggio 2026 alle ore 15:37 UTCresolved

   This incident has been resolved

1. 24 marzo 2026 alle ore 17:12 UTCinvestigating

   We are currently investigating the issue

2. 24 marzo 2026 alle ore 21:07 UTCidentified

   The issue has been identified

3. 24 marzo 2026 alle ore 21:07 UTCidentified

   The issue has been identified and a fix has been deployed and we are currently monitoring

4. 24 marzo 2026 alle ore 21:08 UTCresolved

   This incident has been resolved.

1. 6 marzo 2026 alle ore 14:40 UTCinvestigating

   We are currently investigating.

2. 6 marzo 2026 alle ore 14:43 UTCidentified

   The issue has been identified and we are implementing the fix.

3. 6 marzo 2026 alle ore 15:03 UTCmonitoring

   A fix has been implemented and we are now monitoring

4. 6 marzo 2026 alle ore 15:05 UTCmonitoring

   We are continuing to monitor for any further issues.

5. 6 marzo 2026 alle ore 15:09 UTCresolved

   This incident has now been resolved. Assets synced between 9:00 AM and 10:04 AM EST will have to be resynced.

1. 28 gennaio 2026 alle ore 15:51 UTCinvestigating

   We are currently investigating an issue with global UTM input field not visible

2. 28 gennaio 2026 alle ore 15:51 UTCidentified

   The issue has been identified and we are working to release a fix

3. 28 gennaio 2026 alle ore 16:25 UTCmonitoring

   A fix has been implemented and we are monitoring the release of the fix

4. 28 gennaio 2026 alle ore 19:09 UTCresolved

   This incident has been resolved.

1. 26 gennaio 2026 alle ore 22:38 UTCinvestigating

   We are currently investigating the issue.

2. 27 gennaio 2026 alle ore 01:11 UTCresolved

   A fix has been applied and we are monitoring

1. 19 gennaio 2026 alle ore 21:39 UTCinvestigating

   We are currently investigating an issue with the Knak tracking pixel

2. 19 gennaio 2026 alle ore 22:40 UTCmonitoring

   A fix has been implemented and we are monitoring

3. 20 gennaio 2026 alle ore 22:22 UTCresolved

   This incident has been resolved.

4. 21 gennaio 2026 alle ore 15:24 UTCpostmortem

   ### **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

1. 19 novembre 2025 alle ore 19:35 UTCinvestigating

   We are currently investigating an issue of PDFs not being able to download

2. 19 novembre 2025 alle ore 20:16 UTCresolved

   This incident is resolved PDFs can be downloaded again

1. 20 ottobre 2025 alle ore 14:22 UTCinvestigating

   We are currently investigating this issue.

2. 20 ottobre 2025 alle ore 14:33 UTCmonitoring

   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.

3. 21 ottobre 2025 alle ore 11:31 UTCresolved

   This incident has been resolved.

1. 8 ottobre 2025 alle ore 19:12 UTCidentified

   The issue has been identified and a fix is being implemented.

2. 8 ottobre 2025 alle ore 19:12 UTCidentified

   We are continuing to work on a fix for this issue.

3. 8 ottobre 2025 alle ore 19:18 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 9 ottobre 2025 alle ore 00:11 UTCresolved

   This incident has been resolved.

5. 9 ottobre 2025 alle ore 15:16 UTCpostmortem

   ### 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

1. 12 giugno 2025 alle ore 18:39 UTCidentified

   The issue is believed to be caused by a potential sub-processor outage.

2. 12 giugno 2025 alle ore 20:42 UTCmonitoring

   The issue has been resolved and is being monitored.

3. 12 giugno 2025 alle ore 22:49 UTCresolved

   This incident has been resolved.

4. 19 giugno 2025 alle ore 18:09 UTCpostmortem

   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.

1. 4 aprile 2025 alle ore 14:10 UTCresolved

   This incident has been resolved.

2. 4 aprile 2025 alle ore 19:38 UTCpostmortem

   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

1. 3 aprile 2025 alle ore 12:09 UTCinvestigating

   We are currently investigating this issue.

2. 3 aprile 2025 alle ore 12:29 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 3 aprile 2025 alle ore 12:57 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 3 aprile 2025 alle ore 13:30 UTCresolved

   This incident has been resolved.

5. 4 aprile 2025 alle ore 19:36 UTCpostmortem

   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

1. 27 settembre 2024 alle ore 15:52 UTCinvestigating

   We are currently investigating this issue.

2. 27 settembre 2024 alle ore 15:53 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 27 settembre 2024 alle ore 15:57 UTCresolved

   This incident has been resolved.

1. 4 settembre 2024 alle ore 18:30 UTCresolved

   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.

1. 25 luglio 2024 alle ore 13:18 UTCidentified

   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

2. 25 luglio 2024 alle ore 15:55 UTCresolved

   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.

1. 5 aprile 2024 alle ore 13:45 UTCresolved

   The application was unavailable from 8:16AM to 9:00AM.

2. 5 aprile 2024 alle ore 13:47 UTCpostmortem

   **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.

1. 13 luglio 2023 alle ore 12:37 UTCresolved

   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.

2. 13 luglio 2023 alle ore 12:37 UTCpostmortem

   * 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.