Knak kesinti geçmişi

1. 21 Ekim 2026 13:28 UTCinvestigating

   Mühendislik ve Güvenlik ekiplerimiz PHP2SHELL'a cevap veriyor, Knak'ın da dahil olduğu yaygın olarak kullanılan web yazılımında son zamanlarda açık bir kırılganlık. Sistemlerimizi aktif olarak izliyoruz ve koruyucu önlemleri uyguluyoruz. Verilerinizi korumak ilk gelir. Daha fazla eyleme ihtiyaç duyan bir tehdit görürseniz, Knak çevrimdışı'ı geçici olarak alabilir miyiz, muhtemelen biraz önceden fark edebilir. Herhangi bir kesintinin ekibinizin kampanya oluşturma ve başlatma yeteneğini etkilediğini biliyoruz. Rahatlıktan özür dileriz ve mevcut oldukları gibi durum sayfamızda güncelleştirmeler yayınlayacağız.

2. 21 Ekim 2026 14:27 UTCinvestigating

   Bir yama yapıyoruz

3. 21 Ekim 2026 14:28 UTCinvestigating

   Bir yama yapıyoruz.

4. 21 Ekim 2026 15:12 UTCinvestigating

   Biz yama uyguluyoruz ve şu anda Knak'ı online olarak geri getirmeden önce test ediyoruz. Ön soruşturmamız Knak'ın uzlaşmadığına dair bir gösterge göstermemiştir. Knak'ın geri döndüğü kadar yakında bilmenize izin vereceğiz.

5. 21 Ekim 2026 15:32 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

6. 21 Ekim 2026 15:45 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

7. 21 Ekim 2026 16:03 UTCmonitoring

   Daha fazla sorun için izlemeye devam ediyoruz.

8. 21 Ekim 2026 19:05 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 16 Temmuz 2026 19:17 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

2. 16 Temmuz 2026 22:11 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

3. 17 Temmuz 2026 03:33 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 23 Haziran 2026 14:39 UTCidentified

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

2. 23 Haziran 2026 14:40 UTCidentified

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

3. 23 Haziran 2026 14:42 UTCmonitoring

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

4. 23 Haziran 2026 16:14 UTCresolved

   This incident has been resolved.

1. 8 Mayıs 2026 13:26 UTCmonitoring

   A fix has been implemented and we are monitoring

2. 8 Mayıs 2026 15:37 UTCresolved

   This incident has been resolved

1. 24 Mart 2026 17:12 UTCinvestigating

   We are currently investigating the issue

2. 24 Mart 2026 21:07 UTCidentified

   The issue has been identified

3. 24 Mart 2026 21:07 UTCidentified

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

4. 24 Mart 2026 21:08 UTCresolved

   This incident has been resolved.

1. 6 Mart 2026 14:40 UTCinvestigating

   We are currently investigating.

2. 6 Mart 2026 14:43 UTCidentified

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

3. 6 Mart 2026 15:03 UTCmonitoring

   A fix has been implemented and we are now monitoring

4. 6 Mart 2026 15:05 UTCmonitoring

   We are continuing to monitor for any further issues.

5. 6 Mart 2026 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 Ocak 2026 15:51 UTCinvestigating

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

2. 28 Ocak 2026 15:51 UTCidentified

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

3. 28 Ocak 2026 16:25 UTCmonitoring

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

4. 28 Ocak 2026 19:09 UTCresolved

   This incident has been resolved.

1. 26 Ocak 2026 22:38 UTCinvestigating

   We are currently investigating the issue.

2. 27 Ocak 2026 01:11 UTCresolved

   A fix has been applied and we are monitoring

1. 19 Ocak 2026 21:39 UTCinvestigating

   We are currently investigating an issue with the Knak tracking pixel

2. 19 Ocak 2026 22:40 UTCmonitoring

   A fix has been implemented and we are monitoring

3. 20 Ocak 2026 22:22 UTCresolved

   This incident has been resolved.

4. 21 Ocak 2026 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 Kasım 2025 19:35 UTCinvestigating

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

2. 19 Kasım 2025 20:16 UTCresolved

   This incident is resolved PDFs can be downloaded again

1. 20 Ekim 2025 14:22 UTCinvestigating

   We are currently investigating this issue.

2. 20 Ekim 2025 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 Ekim 2025 11:31 UTCresolved

   This incident has been resolved.

1. 8 Ekim 2025 19:12 UTCidentified

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

2. 8 Ekim 2025 19:12 UTCidentified

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

3. 8 Ekim 2025 19:18 UTCmonitoring

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

4. 9 Ekim 2025 00:11 UTCresolved

   This incident has been resolved.

5. 9 Ekim 2025 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 Haziran 2025 18:39 UTCidentified

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

2. 12 Haziran 2025 20:42 UTCmonitoring

   The issue has been resolved and is being monitored.

3. 12 Haziran 2025 22:49 UTCresolved

   This incident has been resolved.

4. 19 Haziran 2025 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 Nisan 2025 14:10 UTCresolved

   This incident has been resolved.

2. 4 Nisan 2025 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 Nisan 2025 12:09 UTCinvestigating

   We are currently investigating this issue.

2. 3 Nisan 2025 12:29 UTCmonitoring

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

3. 3 Nisan 2025 12:57 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 3 Nisan 2025 13:30 UTCresolved

   This incident has been resolved.

5. 4 Nisan 2025 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 Eylül 2024 15:52 UTCinvestigating

   We are currently investigating this issue.

2. 27 Eylül 2024 15:53 UTCidentified

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

3. 27 Eylül 2024 15:57 UTCresolved

   This incident has been resolved.

1. 4 Eylül 2024 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 Temmuz 2024 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 Temmuz 2024 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 Nisan 2024 13:45 UTCresolved

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

2. 5 Nisan 2024 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 Temmuz 2023 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 Temmuz 2023 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.