Knak Outage History

Started Oct 21, 2026, 01:28 PM UTC· resolved Oct 21, 2026, 07:05 PM UTC

1. investigating Oct 21, 2026, 01:28 PM UTC

   Our Engineering and Security teams are responding to PHP2SHELL, a recently disclosed vulnerability in widely used web software, including components Knak relies on. We are actively monitoring our systems and applying protective measures. Protecting your data comes first. If we see a threat that needs further action, we may take Knak offline temporarily, possibly with little advance notice. We know any disruption affects your team’s ability to build and launch campaigns. We apologize for the inconvenience and will post updates on our status page as they become available.

2. investigating Oct 21, 2026, 02:27 PM UTC

   We're actioning a patch

3. investigating Oct 21, 2026, 02:28 PM UTC

   We're actioning a patch.

4. investigating Oct 21, 2026, 03:12 PM UTC

   We’ve applied the patch and are currently testing it before bringing Knak back online. Our preliminary investigation has shown no indication that Knak has been compromised. We’ll let you know as soon as Knak is back up.

5. identified Oct 21, 2026, 03:32 PM UTC

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

6. monitoring Oct 21, 2026, 03:45 PM UTC

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

7. monitoring Oct 21, 2026, 03:59 PM UTC

   We are continuing to monitor for any further issues.

8. monitoring Oct 21, 2026, 04:03 PM UTC

   We are continuing to monitor for any further issues.

9. resolved Oct 21, 2026, 07:05 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 16, 2026, 07:17 PM UTC· resolved Jul 17, 2026, 03:33 AM UTC

1. identified Jul 16, 2026, 07:17 PM UTC

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

2. monitoring Jul 16, 2026, 10:11 PM UTC

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

3. resolved Jul 17, 2026, 03:33 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 23, 2026, 02:38 PM UTC· resolved Jun 23, 2026, 04:14 PM UTC

1. monitoring Jun 23, 2026, 02:38 PM UTC

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

2. identified Jun 23, 2026, 02:39 PM UTC

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

3. identified Jun 23, 2026, 02:40 PM UTC

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

4. monitoring Jun 23, 2026, 02:42 PM UTC

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

5. resolved Jun 23, 2026, 04:14 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 08, 2026, 01:26 PM UTC· resolved May 08, 2026, 03:37 PM UTC

1. monitoring May 08, 2026, 01:26 PM UTC

   A fix has been implemented and we are monitoring

2. resolved May 08, 2026, 03:37 PM UTC

   This incident has been resolved

Read the full incident report →

Started Mar 24, 2026, 05:12 PM UTC· resolved Mar 24, 2026, 09:08 PM UTC

1. investigating Mar 24, 2026, 05:12 PM UTC

   We are currently investigating the issue

2. identified Mar 24, 2026, 09:07 PM UTC

   The issue has been identified

3. identified Mar 24, 2026, 09:07 PM UTC

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

4. resolved Mar 24, 2026, 09:08 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 06, 2026, 02:40 PM UTC· resolved Mar 06, 2026, 03:09 PM UTC

1. investigating Mar 06, 2026, 02:40 PM UTC

   We are currently investigating.

2. identified Mar 06, 2026, 02:43 PM UTC

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

3. monitoring Mar 06, 2026, 03:03 PM UTC

   A fix has been implemented and we are now monitoring

4. monitoring Mar 06, 2026, 03:05 PM UTC

   We are continuing to monitor for any further issues.

5. resolved Mar 06, 2026, 03:09 PM UTC

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

Read the full incident report →

Started Jan 28, 2026, 03:51 PM UTC· resolved Jan 28, 2026, 07:09 PM UTC

1. investigating Jan 28, 2026, 03:51 PM UTC

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

2. identified Jan 28, 2026, 03:51 PM UTC

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

3. monitoring Jan 28, 2026, 04:25 PM UTC

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

4. resolved Jan 28, 2026, 07:09 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 26, 2026, 10:38 PM UTC· resolved Jan 27, 2026, 01:11 AM UTC

1. investigating Jan 26, 2026, 10:38 PM UTC

   We are currently investigating the issue.

2. resolved Jan 27, 2026, 01:11 AM UTC

   A fix has been applied and we are monitoring

Read the full incident report →

Started Jan 19, 2026, 09:39 PM UTC· resolved Jan 20, 2026, 10:22 PM UTC

1. investigating Jan 19, 2026, 09:39 PM UTC

   We are currently investigating an issue with the Knak tracking pixel

2. monitoring Jan 19, 2026, 10:40 PM UTC

   A fix has been implemented and we are monitoring

3. resolved Jan 20, 2026, 10:22 PM UTC

   This incident has been resolved.

4. postmortem Jan 21, 2026, 03:24 PM UTC

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

Read the full incident report →

Started Nov 19, 2025, 07:35 PM UTC· resolved Nov 19, 2025, 08:16 PM UTC

1. investigating Nov 19, 2025, 07:35 PM UTC

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

2. resolved Nov 19, 2025, 08:16 PM UTC

   This incident is resolved PDFs can be downloaded again

Read the full incident report →

Started Oct 20, 2025, 02:22 PM UTC· resolved Oct 21, 2025, 11:31 AM UTC

1. investigating Oct 20, 2025, 02:22 PM UTC

   We are currently investigating this issue.

2. monitoring Oct 20, 2025, 02:33 PM UTC

   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. resolved Oct 21, 2025, 11:31 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 08, 2025, 07:08 PM UTC· resolved Oct 09, 2025, 12:11 AM UTC

1. monitoring Oct 08, 2025, 07:08 PM UTC

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

2. identified Oct 08, 2025, 07:12 PM UTC

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

3. identified Oct 08, 2025, 07:12 PM UTC

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

4. monitoring Oct 08, 2025, 07:18 PM UTC

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

5. resolved Oct 09, 2025, 12:11 AM UTC

   This incident has been resolved.

6. postmortem Oct 09, 2025, 03:16 PM UTC

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

Read the full incident report →

Started Jun 12, 2025, 06:39 PM UTC· resolved Jun 12, 2025, 10:49 PM UTC

1. identified Jun 12, 2025, 06:39 PM UTC

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

2. monitoring Jun 12, 2025, 08:42 PM UTC

   The issue has been resolved and is being monitored.

3. resolved Jun 12, 2025, 10:49 PM UTC

   This incident has been resolved.

4. postmortem Jun 19, 2025, 06:09 PM UTC

   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.

Read the full incident report →

Started Apr 04, 2025, 12:49 PM UTC· resolved Apr 04, 2025, 01:00 PM UTC

1. resolved Apr 04, 2025, 02:10 PM UTC

   This incident has been resolved.

2. postmortem Apr 04, 2025, 07:38 PM UTC

   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

Read the full incident report →