Spencer Outage History

Started Oct 21, 2026, 12:52 PM UTC· resolved Oct 21, 2026, 12:52 PM UTC

1. resolved Oct 21, 2026, 12:52 PM UTC

   Dear customer, You may have seen news about two critical security vulnerabilities in PHP, a programming language that is widely used to run websites and web applications. The vulnerabilities, known as "PHP2Shell" (CVE-2026-109618 and CVE-2026-109619), could allow attackers to take control of servers that are publicly reachable from the internet. The PHP security team is releasing a fix today, 21 October, at 16:00 Belgian time. We want to let you know where Spencer stands. The servers that run Spencer are not directly reachable from the internet. Every request first goes through a separate security gateway, which only lets it through if it comes from a signed-in user with a valid login. As a result, the automated attacks that are expected to target public PHP servers today cannot reach our systems. This significantly lowers the risk for Spencer. We are still taking this seriously. We will apply the official fix as soon as it is available, and our team is closely monitoring our systems in the meantime. We do not expect any downtime, and you can keep using the app as usual. You do not need to do anything. If you have questions, simply reply to this email or contact our support team. Kind regards, The Spencer team

Read the full incident report →

Started Oct 21, 2026, 11:10 AM UTC· resolved Oct 21, 2026, 05:40 PM UTC

1. investigating Oct 21, 2026, 11:10 AM UTC

   Investigating We are aware of two critical security vulnerabilities in PHP, known as “PHP2Shell” (CVE-2026-109618 and CVE-2026-109619). PHP is a programming language widely used to run websites and web applications, including parts of Spencer. Our team is investigating the potential impact on our platform. Spencer is available and working normally. We will post an update as soon as we know more.

2. resolved Oct 21, 2026, 05:40 PM UTC

   Resolved The fix for the PHP2Shell vulnerabilities has been installed on all Spencer servers using PHP. Spencer remained available throughout, and no action is needed on your side. We will keep monitoring our systems. This incident is now closed.

3. resolved Oct 21, 2026, 05:40 PM UTC

   ## Resolved The fix for the PHP2Shell vulnerabilities has been installed on all Spencer servers using PHP. Spencer remained available throughout, and no action is needed on your side. We will keep monitoring our systems. This incident is now closed.

Read the full incident report →

Started Aug 08, 2026, 12:07 AM UTC· resolved Aug 08, 2026, 12:07 AM UTC

1. resolved Aug 08, 2026, 12:07 AM UTC

   On 8 August 2026, between approximately 02:07 and 02:09 CEST, some Spencer API requests returned errors. The disruption was caused by a restart of our managed Azure database while Azure applied a database engine update. The database recovered automatically and all services resumed normal operation. We are reviewing additional measures to reduce the impact of future database maintenance.

Read the full incident report →

Started Jul 16, 2026, 08:00 AM UTC· resolved Jul 16, 2026, 11:18 AM UTC

1. investigating Jul 16, 2026, 08:00 AM UTC

   The Commslab application is currently unavailable due to a service outage at Amazon Web Services, our hosting provider. Starting at 12:45 AM PDT, we are experiencing increased 5xx errors for CloudFront customers utilizing VPC Origins connectivity. See https://health.aws.amazon.com/health/status for updates from AWS themselves. Please note that our Commslab API is unaffected, so end users of the app are not affected.

2. resolved Jul 16, 2026, 11:18 AM UTC

   Connectivity has been restored. This is the official explanation we received from AWS: Between 09:45 and 13:18 UTC+2, we experienced increased 5xx errors for CloudFront customers utilizing VPC Origins connectivity. Our engineers were automatically engaged and immediately began investigating the root cause. By 11:57 UTC+2, we identified the root cause of the issue as an internal constraint on the fleet that manages connections to private VPC origins. When this constraint was reached, the system responsible for distributing routing configuration to our network processors failed to load the updated configuration data correctly, affecting routing of VPC Origin connections. At 12:52 UTC+2, we took multiple mitigation actions that led to to full recovery at 13:18 UTC+2. Now that the issue has been mitigated, customers who temporarily changed their origin type can safely revert these changes. Customers utilizing other origin types were not affected by this issue. The issue has been resolved and the service is operating normally.

3. resolved Jul 16, 2026, 11:18 AM UTC

   Connectivity has been restored. This is the official explanation we received from AWS: > _Between 09:45 and 13:18 UTC+2, we experienced increased 5xx errors for CloudFront customers utilizing VPC Origins connectivity. Our engineers were automatically engaged and immediately began investigating the root cause. By 11:57 UTC+2, we identified the root cause of the issue as an internal constraint on the fleet that manages connections to private VPC origins. When this constraint was reached, the system responsible for distributing routing configuration to our network processors failed to load the updated configuration data correctly, affecting routing of VPC Origin connections. At 12:52 UTC+2, we took multiple mitigation actions that led to to full recovery at 13:18 UTC+2. Now that the issue has been mitigated, customers who temporarily changed their origin type can safely revert these changes. Customers utilizing other origin types were not affected by this issue. The issue has been resolved and the service is operating normally._

Read the full incident report →