Stripo outage history

Started: 2026-10-08 22:20 UTC Impact: Plugin is unavailable for customers — the editor does not load / does not respond. We have received reports from several customers. What happened: At 22:13 UTC Zabbix reported the agent on the Plugin DB host (pg-plugins.stripo.email, 172.31.13.64) as unavailable; at 22:40 UTC the PostgreSQL monitor for live-plugins failed as well. The Plugin stopped working for customers at ~22:20 UTC. DevOps is investigating. Next update here as soon as we have more information.

The Plugin is fully operational again. DevOps restored the Plugin DB host; we are monitoring and have seen no further errors since 23:18 UTC. A postmortem with root cause, timeline, and action items is being prepared and will be published shortly.

**SUMMARY** On 8 October 2026, between 22:20 and 23:18 UTC, the Stripo Plugin was unavailable: the editor did not load or respond. The outage lasted 58 minutes. No customer data was lost, and other Stripo products were not affected. **WHAT HAPPENED** The database server behind the Plugin lost time synchronization. Two time-sync services were running on the server at once: the standard daemon, which adjusts the clock gradually, and a legacy scheduled job that steps the clock abruptly. A misconfigured schedule made the legacy job run almost every minute. The repeated clock jumps destabilized the server until the Plugin's database became unavailable. **TIMELINE \(UTC, 8 October 2026\)** 21:44 - Clock instability begins on the Plugin database server. 22:13 - Our monitoring raises the first alert for the server. 22:20 - The Plugin stops loading for customers. 22:40 - Monitoring reports the Plugin database as unavailable. 23:00 - First customer reports are received; the on-duty engineer is called in. 23:18 - Service restored. The Plugin is fully operational. **RESOLUTION** Our engineers identified the time-sync conflict and restored the server. The Plugin returned to normal operation at 23:18 UTC and has been under extended monitoring since. **WHAT WE ARE DOING TO PREVENT THIS** * Removing the legacy time-sync job so that this server, and every other production server, uses a single time source. * Adding monitoring for clock drift so that this kind of fault is caught before it affects service. * Changing alert escalation. Our monitoring alerted seven minutes before the outage, but the alert did not page an engineer. Critical alerts on production database servers will now page the on-duty engineer immediately, at any hour. We apologize for the disruption and thank you for your patience. If you were affected and have questions, please contact our support team.

There might be issues while uploading customer’s images inside the editor. Time (UTC) : 2026-10-04T17:03:09

This incident has been resolved.

There might be issues while uploading, changing or removing customer’s images inside the editor. Time (UTC) : 2026-10-04T16:46:22

This incident has been resolved.

There might be issues while viewing, changing or creating new modules in the Modules library inside the editor. Time (UTC) : 2026-10-04T16:43:49

This incident has been resolved.

We are currently experiencing an issue affecting some Stripo Plugin functionality. Some users may be unable to upload images or documents or update storage credentials. Our team is investigating the issue and working to restore normal operation as quickly as possible. Start time: Sep 18, 13:41 UTC

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

This incident has been resolved.

**Root cause** The incident was caused by an issue during a planned rotation of the access key used for the primary image storage service. The new key was not correctly propagated to one of the services responsible for handling storage operations. As a result, requests from that service could not authenticate with the storage, causing image and document upload operations to fail. We also identified a gap in our internal documentation related to the key rotation procedure, which contributed to the incident. **Resolution** The storage credentials were corrected and successfully propagated to all affected services. Once the configuration was updated, upload functionality returned to normal. We have also updated the relevant internal documentation to include the previously missing configuration step. **Preventive actions** We are reviewing the credential rotation procedure to ensure that all dependent services are covered and that configuration changes are validated before and after rotation. We are also improving our internal documentation and verification procedures to reduce the risk of similar incidents in the future. We apologize for the disruption and appreciate your patience while our team worked to resolve the issue.

We are currently experiencing degraded performance in the Stripo Web Editor. Some users may experience long loading times when opening emails, unavailable editor settings and editing functionality, or a “No internet connection” error. For users who already have an email open, changes should continue to be saved via autosave as long as the page is not reloaded. Our team is actively investigating the issue and working to restore normal operation. Start time: Sep 16, 13:25 UTC

This incident has been resolved.

There might be issues while viewing, changing or creating new modules in the Modules library inside the editor. Time (UTC) : 2026-09-09T15:18:49

This incident has been resolved.

There might be issues while viewing, changing or creating new modules in the Modules library inside the editor. Time (UTC) : 2026-09-09T15:13:49

This incident has been resolved.

There might be issues while viewing, changing or creating new modules in the Modules library inside the editor. Time (UTC) : 2026-09-09T15:10:49

This incident has been resolved.

There might be an issue with access to the customer’s account. Time (UTC) : 2026-09-06T07:17:04

This incident has been resolved.

We are aware of an issue with the Stripo Plugin: the editor may fail to initialize and does not load for end users. Our team has identified the affected service and is working on a fix. We will post an update as soon as we have more information.

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

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

This incident has been resolved.

At 13:45 UTC the AWS host running the database and cache for our plugin environment failed. Auto-recovery restarted it by 14:00 UTC, but the cache service and several microservices required manual restarts. Full recovery: ~15:00 UTC. **Impact \(UTC\).** Autosave was unavailable 13:48–13:57, then severely slow \(~86 s per request vs. under 7 s normally\) until ~14:40. Some plugins using external AutoSave callbacks saw saves fail. Co-editing was degraded 14:16–15:00. Editor initialization also failed for some users early on. **Data.** No evidence of loss: crash recovery completed correctly, all patches that reached the database were persisted, and duplicate resubmissions were safely rejected. Contact us with a timestamp if you suspect otherwise. **Cause.** Hardware failure on the underlying AWS host. It escalated because autosave retries external callbacks synchronously inside the request, exhausting the database connection pool; the cache had no auto-start on reboot; and connection pools did not self-heal. No alarm covered host status or cache availability, so detection came from user reports. **Fixes.** Alerting on host status checks and cache availability; cache auto-start with a health check; connection pool recovery; moving external callbacks out of the request path; alerts on pool saturation, error rate and callback latency; a redundancy review for this environment. We apologize for the disruption. If the impact on your users differed from the above, please contact our support team.

We are investigating reports of users being unable to log in, seeing missing team members, or experiencing slow loading of emails. Our team is working to identify the cause.

We have identified the root cause: an internal caching service (Redis) ran out of memory and began rejecting writes. As a result, permission checks bypassed the cache and put excessive load on the account service, causing slow responses, login failures, and missing account data. We have increased the cache capacity and are preparing a permanent fix.

Cache capacity has been increased and the system is recovering. Response times are returning to normal as caches warm up. A permanent fix is being deployed.

The permanent fix has been deployed to all production clusters and all systems are operating normally. During the incident (July 30, 22:48 UTC – July 31, ~04:30 UTC, with residual slowness until ~08:49 UTC), some users experienced login failures, missing team member data, and slow loading of emails. No data was lost. We have added memory-usage alerting to detect this class of issue before it affects users. We apologize for the inconvenience.

On July 28, between approximately 1:28 PM and 1:58 PM (UTC), the Stripo Plugin failed to initialize for embedded integrations. The issue was caused by degraded performance of an internal statistics service, which slowed down plugin initialization requests. Our team restarted the affected service and temporarily disabled statistics collection for plugin initializations to restore normal operation. The plugin is now loading as expected. We apologize for any inconvenience this may have caused.

There might be issues while uploading, changing or removing customer’s images inside the editor. Time (UTC) : 2026-07-25T09:18:22

This incident has been resolved.

On July 24 between 09:20 and 09:50 UTC, real-time co-editing in the plugin editor was temporarily unavailable. During a scheduled release, a database schema update took longer than expected and briefly overloaded the database, which caused the co-editing service to restart. Our team identified the cause and fully restored the service by 09:50 UTC. No customer data was lost, and all other Stripo functionality remained available throughout. We've since added safeguards to our release process to prevent a recurrence.

There might be an issue with access to the customer’s account. Time (UTC) : 2026-07-23T09:39:04

[Comment from Opsgenie]Dmitry Kudrenko acknowledged alert: "Partial Outage in work of Stripo Account Backend part"

This incident has been resolved.

Stripo Security Incident How this started We received two customer reports regarding unusual activity associated with ESP accounts. While an individual report could reasonably have been attributed to a variety of causes, including configuration issues, legacy integrations, or provider-specific factors, the second report involved a different ESP provider and exhibited similar characteristics. At that point, we determined that the observed pattern warranted a comprehensive security review and initiated a broader investigation. Current status As we identified accounts with stored ESP credentials, we reached out asking those customers to rotate their keys as a priority. This was not a single, complete pass: as our investigation continued, we identified additional accounts that required the same notification, and we've been contacting them as they're confirmed. If you have ESP credentials connected to Stripo and haven't rotated them yet: 1. Revoke the old key there; generating a new key doesn't automatically disable the old one. 2. Generate a new key in your ESP account. 3. Update the new key in Stripo under Project Settings → Integrations . 4. Review your ESP or CRM account's recent activity: login history, contact list changes, and any campaigns or sends you don't recognize. One reminder while all this is underway: we will never ask you to send a key, token, or password by email or in a support chat. Ongoing investigation Our investigation is continuing. Should we identify any confirmed findings that are material to affected customers, we will communicate them without undue delay.

Jul 20, 2026 - 18:15 UTC What we've fixed Following our initial communication, we have implemented a number of additional security enhancements : 1. Credential protection audit . We reviewed how credentials are stored across our systems and implemented additional encryption for credential data where enhanced protection was identified as appropriate. 2. Implemented additional browser-side protections to address an identified browser-related exposure scenario . Stored credentials are no longer sent back to the browser when the integrations screen is opened. This, combined with the storage enhancement above, significantly reduces potential exposure risks associated with credential handling. 3. Completed a full logging audit . We reviewed our logging systems end-to-end and updated our logging configuration to prevent credential values from being recorded in application logs. 4. Cleaning up stale data . We deleted old ESP connections that had been kept after they stopped being used, and we're in the process of removing old, unused keys still on file. Based on our investigation to date, we have not identified any indication of impact on the Stripo Plugin . Stripo does not store customers' financial or payment information. Accordingly, based on our investigation to date, we have not identified any impact on financial or payment data maintained by Stripo. Based on the information currently available, we have not identified any impact on our primary production systems. The activity identified to date appears to have been associated with a backup environment . We've implemented additional security measures for that environment and are continuing to assess whether there is any broader impact as part of our ongoing investigation. Compliance certifications We maintain an independently audited security program, including SOC 2 and ISO certifications. As part of this investigation, we identified opportunities to further strengthen certain technical controls related to the handling of export credentials. We have implemented additional safeguards addressing the matters identified during our investigation. We are also incorporating the findings from this investigation into our security program, risk assessment processes, technical controls, and future audit activities. These findings have informed additional technical safeguards and will continue to be incorporated into our security controls and audit program. Security certifications demonstrate that an organization's security program has been independently assessed against recognized standards. Like any security framework, they support continuous improvement as new risks and implementation considerations are identified. Ongoing investigation Our investigation remains ongoing. As part of this work, we continue to review access activity relating to the database instances where the relevant data is stored. Should we identify confirmed findings that are material to affected customers, we will communicate them without undue delay.

Incident period: 6–18 July 2026 · Published: 21 July 2026 Final Incident Report — Unauthorized access to stored integration credentials Summary Between 6 and 18 July 2026, an unauthorized actor gained access to an internal, non‑customer‑facing environment that had read access to a restricted, read-only replica containing a limited subset of production data. Based on our completed investigation, the actor executed read queries that resulted in access to certain information stored within that environment, including certain third‑party ESP/export credentials that customers had stored in Stripo for their integrations, together with certain account records. Upon identifying the activity, we isolated and decommissioned the environment involved, implemented remediation measures, and completed our investigation into the incident. The incident was reported solely through a client request and could not have been detected through our standard monitoring. What data was affected Based on our completed investigation, the information identified as having been accessed included certain third‑party ESP/export credentials that customers had saved to connect their integrations, together with certain associated account records. Account authentication data . Stripo passwords are stored hashed and salted — never in plain text, in line with security best practices, so they were not exposed in a usable form. Because a determined attacker could, in theory, attempt to crack salted hashes over time, we did not take chances: we proactively reset every Stripo password even though there is no indication that the hashes can be practically recovered. Each user simply sets a new password at their next sign‑in. What we have done 1. Contained the incident by cutting off and decommissioning the internal environment involved. 2. Extended encryption at rest to all stored ESP/export credentials, including those that were not already encrypted ( keys held in a managed AWS KMS ). 3. Stopped returning credentials to the browser when integration screens are opened. 4. Reviewed application logging and removed credential values from the limited scenarios in which they could appear. While our investigation did not identify evidence that application logs formed part of the attack path, we nevertheless implemented this additional safeguard as part of our broader remediation efforts. 5. Purged old/inactive credentials retained after they were no longer in use. 6. For Klavio, HubSpot, Zoho, and AWeber, we automatically revoked all authorization tokens. 7. Conducted a full review across our infrastructure perimeter: audited all security groups and access paths to system nodes, rotated the passwords for all databases, restricted the read‑only replica to internal‑only access, and reviewed access held by internal services and staff, tightening it under least‑privilege principles. 8. Proactively reset all user passwords and invalidated sessions. 9. Added monitoring and alerting for authentication to internal tools, external database connections, and bulk reads of sensitive tables. We operate under recognized security and data‑protection standards, including our SOC 2 program. As part of our ongoing security program, we continue to strengthen our technical and organizational controls based on the findings of this investigation. Who was not affected Customers who exported only to file formats (HTML, AMP HTML, PDF, EML, image, etc.) never stored any credentials with us and are not affected. Credentials were also not accessed for the following providers: CleverTap, Customer.io, Follow Up Boss, Google Cloud, MailerCloud, MailerLite, Mailtrap, Make, Mindbaz, n8n, Netcore, OneSignal, Optimove, Postup, Pubrio, Rapidmail, Reteno, Selzy, Sender.net, Ticketor, Unione, Insider, Voizee, WhatCounts, Yespo. Plugin and self‑hosted deployments were not affected — the environment and replica involved are part of Stripo Cloud infrastructure, not the self‑hosted product or the Stripo plugin. Long‑inactive accounts . Under our data‑retention policy and in line with our GDPR obligations, inactive customer accounts and their personal data are routinely deleted, so information belonging to long‑inactive customers was not present in this environment and could not have been exposed. Payment data Based on our investigation, no full payment card numbers (PANs) or CVV codes were identified as having been accessed. Card payments are processed by our payment providers (Stripe and PayPal), and Stripo does not store full payment card numbers or CVV codes. Working with our ESP partners Because these are third‑party credentials, we are proactively contacting the ESP providers involved, in the spirit of partnership and to protect our mutual customers, so affected credentials can be revoked on their side as an additional safeguard. What we recommend our customers do 1. If your provider is not in the “Who was not affected” section above and you haven't already: rotate the ESP credentials connected to your Stripo account — revoke the old key at your provider, generate a new one, and update it in Stripo (Project Settings → Integrations). For OAuth‑based integrations, revoke Stripo's authorization at your provider and reconnect. 2. Review your ESP/CRM activity from early July onward — sign‑ins, contact‑list changes, and any campaigns, sends, or exports you don't recognize. Rotating a key stops future use but doesn't undo activity that already occurred. 3. Your Stripo password has already been reset — set a new one at your next sign‑in. Closing We sincerely regret that this incident occurred. We've contacted affected customers directly and remain available to answer follow‑up questions on request. Contact: [email protected].

There might be issues while uploading, changing or removing customer’s images inside the editor. Time (UTC) : 2026-07-07T15:26:22

This incident has been resolved.

There might be an issue related to exporting of email templates as PDF files from the editor. Time (UTC) : 2026-07-01T03:52:37

This incident has been resolved.

There might be an issue related to sending test messages to specified email addresses and/or related to testing email templates with Email on Acid. Time (UTC) : 2026-06-18T13:43:15

This incident has been resolved.