数据库复制延迟导致事件 App、 Studio 和开发者 API 的数据不一致
Issues轻微事件
- monitoring
我们的一个数据库复制件上的数据复制延迟,可能导致一些用户看到接口中过时或不一致的信息. 一些用户也可能偶尔出错. 没有丢失数据 。 我们的小组已经采取行动,我们正在密切监测复制品的复制情况。 如果看到不一致,请刷新页面。 这件事一解决,我们再发布最新消息.
- resolved
此事已决. 复制完全恢复同步,平台正常运行.
自动翻译自官方事件更新。
33 Swapcard incidents · 2020年7月 — official updates, affected components, duration and resolution details.
我们的一个数据库复制件上的数据复制延迟,可能导致一些用户看到接口中过时或不一致的信息. 一些用户也可能偶尔出错. 没有丢失数据 。 我们的小组已经采取行动,我们正在密切监测复制品的复制情况。 如果看到不一致,请刷新页面。 这件事一解决,我们再发布最新消息.
此事已决. 复制完全恢复同步,平台正常运行.
自动翻译自官方事件更新。
在协调世界时03:00至10:25之间,开发者API可能已经根据一些请求返回了断断续续的错误. 在此窗口中失败的请求可以安全重试 。 这个问题已经解决,开发者API正在正常运行.
我们正在调查一个问题,即开发者API可能会根据一些请求回回断断续续的错误. 大多数请求通常都是成功的。 失败的请求可以安全地重审. 一旦掌握更多信息,我们将公布最新情况.
自动翻译自官方事件更新。
我们正在调查一个影响推动通知的问题。 有些用户可能不会收到按压通知. 其他所有平台功能都正常工作. 我们的团队正在寻找解决办法,一旦我们掌握了更多信息,我们将在此公布最新情况.
已采用固定办法,通常会再次发出催促通知。 我们正在监测,以确保一切恢复正常.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一事件已经得到解决.
自动翻译自官方事件更新。
这一问题已经确定,一个解决办法正在实施之中.
已经执行了一项固定措施。 我们正在恢复分析数据,在此过程中没有数据损失.
这一事件已经得到解决.
自动翻译自官方事件更新。
8月31日星期一,参展者和组织者扫描徽章开始在扫描后看到出错,扫描后作为离线扫描存储在设备上. 这发生在有工作互联网连接的设备上,因此最初被误认为是会场网络问题. 在iOS上,一些设备只显示被窃听时未打开的红色横幅. ** 没有丢失铅数据。 ** 两个机制同时保护数据。 服务器方面,每条线索在扫描时保存到我们的主数据库,在步骤失败之前,所以即使应用程序报告出错,线索也已经存在. 设备方面,应用程序的离线模式捕获了扫描,并在扫描恢复后同步. 由于同一扫描的重复提交更新了现有铅而不是添加了新的铅,因此这并没有产生重复的铅. 原因是徽章扫描路径所特有的. 在该窗口期间,登记、活动页、会议、短信、出口和组织者后台没有受到影响.
自动翻译自官方事件更新。
Sherlock is currently experiencing degraded performance due to an inference capacity issue. We are working with our inference providers to restore full capacity as quickly as possible.
A fix to increase capacity is currently under testing.
Inference capacity has been fully restored
The issue has been identified and a fix is being implemented.
This incident has been resolved.
We are providing a detailed post-mortem report regarding the service disruption that affected Swapcard Login on June 19th, 2026. This issue was caused by an upgrade of our cache cluster, which led to temporary login failures. The goal of this post-mortem is to share insights from our assessment and the steps taken to resolve the issue while providing transparency to our customers. **Summary** As part of a planned upgrade to increase the capacity of our cache cluster, we carried out a zero-maintenance-window upgrade, a rollout designed to require no scheduled downtime. During the rollout, a misconfiguration that was not identified in our pre-production environment affected the login service in production, resulting in a period during which users were unable to sign in. **Timeline (UTC)** [16:35] — Migration of production services to the upgraded cache cluster proceeds as part of the zero-downtime rollout. [16:38] — The login service begins failing to connect to the cache; sign-in errors start. [16:42] — Incident detected and investigation begins. [16:45] — Root cause identified: corrected configuration deployed to login. [16:48] — Login fully recovers; error rates return to normal. **Mitigation** We updated the login service to connect to the upgraded cache cluster using the correct configuration, restoring sign-in functionality. As a precaution, we reviewed all other production services and corrected one additional service that carried the same latent misconfiguration before it could cause further impact. **Root cause** During a planned upgrade to increase the capacity of our cache cluster, a misconfiguration was introduced that left the Login service unable to connect to the upgraded cluster. The issue was not identified in our pre-production environment and surfaced in production during the rollout, causing sign-in to fail until the configuration was corrected. **Next steps** We are adding automated checks to (1) detect any reference to a cache cluster scheduled for decommission and (2) verify configuration parity between our pre-production and production environments, so this class of issue is caught before reaching production in future upgrades.
This incident has been resolved.
### **Summary** Approximately two weeks ago, users began experiencing disruption when accessing analytics data within App Studio. Initial investigation did not immediately identify the root cause; a deeper analysis ultimately traced the issue to a routine infrastructure consolidation that was capping database capacity below the threshold required to handle specific event analytics queries spanning long date ranges. Full service has since been restored following a targeted increase in database resources. ### **Timeline** * **2026-03-11 19:32 UTC** — Incident created. Initial investigation launched following a rise in user-reported loading issues on analytics, despite no prior performance degradation. The initial investigation did not surface a clear root cause at this stage. * **2026-03-18 10:45 UTC** — Automated monitoring triggered alerts for elevated database error rates, corroborated by incoming user reports of analytics failures. * **2026-03-19 09:30 UTC** — Deeper analysis by the Engineering team identified the root cause: high latency and query failures isolated to specific event analytics queries over long date ranges, linked to the earlier infrastructure consolidation. * **2026-03-19 09:40 UTC** — Remediation plan executed: database resources scaled up to meet query load demands. * **2026-03-19 10:05 UTC** — Database performance stabilized; analytics functionality verified as fully restored. ### **Resolution** To restore service, database resources were immediately scaled up to accommodate the throughput required by analytics queries. Once additional capacity was provisioned, query timeouts ceased and application stability was reestablished. The system remained under active monitoring until no further degradation was observed, at which point the incident was marked resolved. ### **Root Cause Analysis** The incident was caused by a capacity mismatch introduced during a routine infrastructure consolidation. Such consolidations are a standard part of our infrastructure lifecycle and are conducted with active monitoring in place to ensure continued performance across all services. In this instance, however, the capacity allocated to the Analytics Database was capped at a level that, while adequate for standard workloads, could not sustain the computational demands of specific event analytics queries executed over long date ranges. The initial investigation did not immediately surface this connection; it was only through deeper analysis that the consolidation was identified as the underlying cause. When these queries were executed, they exceeded available processing capacity, resulting in database timeouts and repeated failures of the analytics service; conditions that persisted until capacity was restored. The investigation also surfaced a broader pattern: a gradual uptick in user-reported loading issues over the preceding two weeks, despite analytics having previously performed reliably. This indicated the capacity cap had been quietly eroding performance well ahead of the full outage. ### **Conclusion** We are straightening our processes to prevent recurrence. Monitoring coverage applied during database consolidations will be strengthened to detect query latency degradation earlier, and capacity planning will be refined to better account for the demands of specific event analytics queries over long date ranges. Looking further ahead, the team is actively working on delivering a fully revamped analytics pipeline to production later this year. This is not an incremental improvement; the new pipeline is being built to deliver deeper, richer metrics that give event organizers a comprehensive view of their event performance.
This incident has been resolved.
## Summary On March 11, 2026, we experienced a service disruption affecting the visibility of speaker and attendee profiles across multiple events. The incident was triggered by a timing issue during a scheduled infrastructure update — a data refresh was initiated before new field definitions had fully propagated to our Search Engine, causing the indexation system to be built from an outdated configuration. Our Search Engine relies on an indexation system to serve profile data quickly across events. When the refresh completed against the stale configuration, new fields were rejected due to strict schema enforcement, leaving profiles absent from search results and listings. The goal of this post-mortem is to share our assessment and the steps taken to resolve the issue, while providing full transparency to our customers. ## Timeline | Time \(UTC\) | Event | | --- | --- | | Mar 11 – 11:04 | Infrastructure update deployed to production. Changes confirmed as applied. | | Mar 11 – 13:21 | Data refresh initiated as part of the planned release process. Previous indexation remained fully functional during this period. | | Mar 11 – 13:42 | Release step complete. Data refresh running, expected duration ~3–4 hours. | | Mar 11 – 14:49 | Configuration mismatch errors first logged internally. | | Mar 11 – 15:33 | Data refresh reported as complete. Spot checks passed. Final release step initiated. | | Mar 11 – 16:52 | Reports of missing profiles across multiple events surfaced. Incident response team immediately activated. | | Mar 11 – 17:29 | Root cause identified in under few minutes: indexation system had been built before the new fields were fully available. Internal alerts corroborated the finding. | | Mar 11 – 18:08 | Analysis completed confirming the refresh did not produce an indexation with the expected new fields. | | Mar 11 – 18:39 | Corrective data refresh triggered with the correct configuration fully in place, within 30 minutes of initial reports. | | Mar 11 – 18:43 | New indexation confirmed to contain the correct fields. Full refresh in progress. | ## Resolution Once the root cause was identified, the team immediately initiated a new data refresh against the correct, fully propagated configuration. Profile visibility and search behavior were monitored throughout the process. Once the refresh completed, all profiles returned to normal search and listing behavior. ## Root Cause Analysis The root cause was a race condition between the deployment of new Search Engine field definitions and the triggering of a data refresh. The refresh started before the new configuration had fully propagated, causing the indexation system to be built from a stale schema. Due to strict schema enforcement, subsequent write operations referencing the new fields were rejected, leaving profiles absent from search results and listings. Several factors contributed to this incident: * **Ambiguous deployment signal:** A pipeline warning created uncertainty around whether the deployment had completed cleanly. * **Insufficient spot checks:** Post-refresh verification passed at a surface level, masking the underlying schema mismatch until live traffic exposed it. **Short-term improvements:** * Add a mandatory pre-refresh validation step to confirm the Search Engine schema matches the expected configuration before any refresh is initiated. * Update the release process to include explicit schema validation checkpoints for sub field, as a required step. ## Conclusion This incident stemmed from a timing edge case in our release process. The improvements listed above reflect our commitment to preventing similar incidents and maintaining a reliable platform for all our customers. For any questions or concerns regarding this incident, please reach out to our support team.
We are currently investigating this issue.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
This incident has been resolved.
The issue has been identified and a fix is being implemented.
Please see our post-mortem below regarding the 404 error page from May 5h, 2022 at 13:11 UTC through to 13:20 UTC. It is our goal in this post-mortem to provide details on our initial assessment of the incident communicated on the Swapcard status page and to describe the remediation actions that we have taken to restore service. ## **Incident summary** On Tuesday, May 5th at 13:12 UTC, we experienced a 404 error page our studio due to a miss configuration on the web application \([studio.swapcard.com](http://studio.swapcard.com)\). On Tuesday, May 5th at 13:12 UTC, our infrastructure team has been automatically alerted of an un usual 404 error page on the web application \([studio.swapcard.com](http://studio.swapcard.com)\). Swapcard monitoring detected the start of disruption and activated the Swapcard Incident Response team. Swapcard’s team worked to triage and mitigate the incident by checking any recent changes on the web application \([studio.swapcard.com](http://studio.swapcard.com)\) configuration and revert to an older version. In parallel, the cause of the issue was investigated and short & mid term plans were put in place. ## **Mitigation deployment** At 13:13 UTC our infrastructure team has immediately revert the configuration changes for studio.swapcard.com. The switch process took around ~6min. The error reporting has stopped as the update propagated through our infrastructure. Swapcard engineering then monitored [studio.swapcard.com](http://studio.swapcard.com) to ensure full and proper recovery. As a result of the deployment of that change, customers would then see a reduction of the 404 error messages. At 13:20 UTC, Swapcard confirmed that the update was completed and no further error detected or reported. Swapcard’s Engineering team identified the root cause, and by ~14:31 UTC has redeploy the configuration change corrected. ## **Event Outline** ### **Duration Summary** Time alerted to the outage: 1 minutes Time to identify the source of disruption: ~2 minutes Time to initiate recovery: ~6 minutes Time to monitor and restore service pre-crash: ~1 minutes ### **Events of 2022 May 5th \(UTC\)** \(13:11 UTC\) | Initial onset of the error rate increase \(13:12 UTC\) | Disruption identified by Swapcard monitoring \(13:13 UTC\) | Configuration revert has been initiated \(13:12 UTC\) | Swapcard status post activated \(13:19 UTC\) | 404 error page decrease and recovered \(13:20 UTC\) | Incident mitigated \(13:20 UTC\) | Status post resolved \(14:31 UTC\) | Swapcard Engineering redeploy the configuration change corrected Affected customers may have been impacted by varying degrees and with a shorter duration than described above. ## **Forward Planning** Swapcard has deployed a permanent fix for this incident in accordance with our high standard in terms of deliverability. **We consider the likelihood of a recurrence of this issue to be extremely low.**
This incident has been resolved.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
On Monday, January 17th at 15:30 UTC, we experienced an increase response time on our event app, the incident has lasted ~2min
Please see our post-mortem below regarding the increase error rate on community list for event planner accounts only from November 29th, 2021 at ~14:17 UTC. On Monday, November 29th at ~14:19 UTC, we experienced an increase error rate on the community list page on event planner accounts only, this is due to a data upgrade on organisation rights management in accordance to our zero downtime strategy. On Monday, November 29th at ~14:17 UTC, our infrastructure team has been automatically alerted of an un usual increase error rate on community list pages for event planner account. Swapcard monitoring detected the start of disruption and activated the Swapcard Incident Response team. Swapcard’s team worked to triage and mitigate the incident by reverting the data upgraded to their original value and reverted services configuration. In parallel, the cause of the issue was investigated and short & mid & long term plans were put in place. Swapcard has deployed a permanent fix for this incident in accordance with our high standard in terms of deliverability. Affected customers may have been impacted by varying degrees and with a shorter duration than described above, the engineering team confirmed that no disruption for attendees & exhibitors has been reported. We consider the likelihood of a recurrence of this issue to be extremely low.
Please see our post-mortem below regarding the increase error rate on video call & roundtable from November 3th, 2021 at 17:05 UTC through to 17:47 UTC. It is our goal in this post-mortem to provide details on our initial assessment of the incident communicated on the Swapcard status page and to describe the remediation actions that we have taken to restore service. ## **Incident summary** On Thursday, November 3th at 17:05 UTC, we experienced an increase error rate on video call & roundtable on our event app due to a authentification configuration issue between our platform and our video call partner. On Thursday, November 3th at 17:05 UTC, our infrastructure team has been automatically alerted of an un usual increase error rate on video call & roundtable feature. Swapcard monitoring detected the start of disruption and activated the Swapcard Incident Response team. Swapcard’s team worked to triage and mitigate the incident by switching from one to the other backup video call partner account to alleviate customer impact. In parallel, the cause of the issue was investigated and short & mid & long term plans were put in place. ## **Mitigation deployment** At 17:08 UTC our infrastructure team has immediately trigger the switch to our backup plan for video call outage in to alleviate the customer impact. The switch process took around ~15min. The error reporting has stoped as the update propagated through our different endpoints. Swapcard engineering then monitored all the endpoints to ensure full and proper recovery. As a result of the deployment of that change, customers would then see a reduction of the error messages. At 17:53 UTC, Swapcard confirmed that the update was completed and no further error detected or reported. Swapcard’s Engineering team identified the root cause, and by ~18:20 UTC has re-enabled the original authentification process with our video call partner. ## **Event Outline** ### **Duration Summary** Time alerted to the outage: 1 minutes Time to identify the source of disruption: ~10 minutes Time to initiate recovery: ~15 minutes Time to monitor and restore service pre-crash: ~10 minutes ### **Events of 2021 November 3th \(UTC\)** \(17:05 UTC\) | Initial onset of the error rate increase \(17:05 UTC\) | Disruption identified by Swapcard monitoring \(17:08 UTC\) | Switch from backup identical provider account has been initiated \(17:27 UTC\) | Swapcard status post activated \(17:40 UTC\) | Video & roundtable error rate decrease and recovered \(17:47 UTC\) | Incident mitigated \(17:53 UTC\) | Status post resolved \(18:20 UTC\) | Swapcard Engineering identified the original issue Affected customers may have been impacted by varying degrees and with a shorter duration than described above. ## **Forward Planning** Swapcard has deployed a permanent fix for this incident in accordance with our high standard in terms of deliverability. **We consider the likelihood of a recurrence of this issue to be extremely low.**
This incident has been resolved.
A fix has been implemented and we are monitoring the results.
The issue has been identified and a fix is being implemented.
We are currently investigating this issue.
This incident has been resolved.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
Please see our post-mortem below regarding the increase response time on our chat endpoint from September 2th, 2021 at 15:38 UTC through to 15:41 UTC. It is our goal in this post-mortem to provide details on our initial assessment of the incident communicated on the Swapcard status page and to describe the remediation actions that we have taken to restore service. ## **Incident summary** On Thursday, September 2th at 15:38 UTC, we experienced an increase response time on our event app due to one of our replicate database server being under pressure because of a specific query. On Thursday, September 2th at 15:37 UTC, our infrastructure team has been automatically alerted of an increase response time on our event app, requests were replying in a twice higher average time compare to the usual average response time. Swapcard monitoring detected the start of disruption at ~15:37 UTC and activated the Swapcard Incident Response team. Swapcard’s team worked to triage and mitigate the responsible database queries to alleviate customer impact. In parallel, the cause of the issue was investigated and short & mid & long term plans were put in place. ## **Mitigation deployment** At 15:39 UTC our monitoring system had immediately turned off the responsible database that was under pressure to mitigate the impact on our services and recover a proper event app response time. The turn off process took around ~15s. Event app increase response time stopped as the database turned off configuration propagated through our endpoints. Swapcard engineering team then monitored the event app endpoints to ensure full and proper recovery. As a result of the deployment of that change, customers would then see a reduction of the chat loading time and error messages. At 15:43 UTC, Swapcard confirmed that the update was completed and response time restored to pre-incident levels and ensuring that the traffic was back to the pre-incident rate. Swapcard’s Engineering team identified the cause, and by ~15:50 UTC has re-enabled the impacted database replication, the root cause has also been identified and solved. ## **Event Outline** ### **Duration Summary** Time alerted to the outage: 1 minutes Time to identify the source of disruption: ~2 minutes Time to initiate recovery: ~15 seconds Time to monitor and restore response time pre-crash: ~2 minutes ### **Events of 2021 September 2th \(UTC\)** \(15:37 UTC\) | Initial onset of the response time increase \(15:38 UTC\) | Disruption identified by Swapcard monitoring \(15:38 UTC\) | Swapcard status post activated \(15:39 UTC\) | Automatic monitoring system mitigated the issue \(15:40 UTC\) | Impacted event app began to recover \(15:41 UTC\) | Incident mitigated, pre-incident response time restored \(15:43 UTC\) | Status post resolved \(15:50 UTC\) | Swapcard Engineering identified the issue Affected customers may have been impacted by varying degrees and with a shorter duration than described above. ## **Forward Planning** Swapcard has deployed a permanent fix for this incident in accordance with our high standard in terms of deliverability.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
Please see our post-mortem below regarding the increase response time on our chat endpoint from August 10th, 2021 at 16:48 UTC through to 17:15 UTC. It is our goal in this post-mortem to provide details on our initial assessment of the incident communicated on the Swapcard status page and to describe the remediation actions that we have taken to restore service. ## **Incident summary** On Tuesday, August 10th at 16:48 UTC, we experienced an increase response time on our chat endpoint due to the pressure of two database queries \(Count unread channel & Number of active one to one conversation\) on our chat database. On Tuesday, August 10th at 16:48 UTC, our infrastructure team has been automatically alerted of an increase response time on our chat endpoint, requests was replying in an average of 300ms compare to the usual average of 4ms response time. Swapcard monitoring detected the start of disruption at ~16:47 UTC and activated the Swapcard Incident Response team. Swapcard’s team worked to triage and mitigate the responsible database queries to alleviate customer impact. In parallel, the cause of the issue was investigated and short & mid & long term plan were put in place. ## **Mitigation deployment** At 16:52 UTC, Swapcard’s Engineering team identified the cause, and by 16:57 UTC had immediately turned off the responsible database queries to mitigate the impact on our services and recover a proper chat endpoint response time, the turn off process took us around ~8 min to ensure proper execution and deployment. Chat increase response time stopped as the update propagated through our chat endpoints. Swapcard engineering then monitored all the chat endpoints to ensure full and proper recovery. As a result of the deployment of that change, customers would then see a reduction of the chat loading time and error messages. At 17:30 UTC, Swapcard confirmed that the update was completed and response time restored to pre-incident levels and ensuring that the traffic was back to the pre-incident rate. ## **Event Outline** ### **Duration Summary** Time alerted to the outage: 01 minutes Time to identify the source of disruption: ~5 minutes Time to initiate recovery: ~5 minutes Time to monitor and restore response time pre-crash: ~12 minutes ### **Events of 2021 August 10 \(UTC\)** \(16:46 UTC\) | Initial onset of the response time increase \(16:47 UTC\) | Disruption identified by Swapcard monitoring \(16:48 UTC\) | Swapcard status post is activated \(16:52 UTC\) | Swapcard Engineering identified the issue \(17:05 UTC\) | Swapcard Engineering mitigate the issue \(17:13 UTC\) | Impacted chat endpoint began to recover \(17:15 UTC\) | Incident Mitigated, pre-incident response time restored \(17:38 UTC\) | Status post resolved Affected customers may have been impacted by varying degrees and with a shorter duration than as described above. ## **Forward Planning** Swapcard has deployed a permanent fix for this incident by optimising the responsible database queries and implemented technical measures to ensure proper covering of other databases queries on the chat endpoint. In accordance with our high standard in terms of deliverability, Swapcard conducted during the 5 following days post incident a series of optimisation to prevent further similar issues on the chat endpoint. **We consider the likelihood of a recurrence of this issue to be extremely low and will further reduce the risk as we make improvements.**
We are currently investigating this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
Please see our post-mortem below regarding a service delivery disruption that affected Swapcard customers from July 6th, 2021 at 05:58 UTC through to 6:18 UTC. It is our goal in this post-mortem to provide details on our initial assessment of the incident communicated on the Swapcard status page and to describe the remediation actions that we have taken to restore service. ## **Incident summary** On Tuesday, July 6th at 06:01 UTC, we experienced an increase error rate due to a rolling update \(capacity and security\) apply on our caching sever \(Redis\). On Tuesday, July 6th at 06:01 UTC, our private cloud provider has deployed an automatic update on our main caching server \(Redis\). This automatic change is applied in accordance with Swapcard standard infrastructure & security change and enhancement practices. Cluster are configured in High Availability/Failover mode to prevent any disruption of services and support our zero downtime strategy. An issue in our hot switch mechanism has prevent our services to take in consideration the primary/secondary switch has cause a significant disruption on the content delivery. Swapcard monitoring detected the disruption at 05:58 UTC and activated the Swapcard Incident Response team. Swapcard’s team worked to triage and restore services to alleviate customer impact. In parallel, the cause of the issue was investigated and mitigations were put in place. ## **Mitigation deployment** At 05:58 UTC, Swapcard’s Engineering team identified the cause, and by 06:08 UTC had deploy manually a configuration change to reflect the primary/secondary changes. Content delivery disruption stopped as the update propagated through our services. Swapcard engineering then monitored all the services to ensure full and proper recovery by 6:17 UTC. As a result of manually deploying this configuration change, customers would then see a reduction in the 5XX errors and error messages. At 06:23 UTC, Swapcard confirmed that the update was completed and capacity restored to pre-incident levels, ensuring that the traffic was back to the pre-incident rate. ## **Event Outline** ### **Duration Summary** Time alerted to the outage: 01 minutes Time to identify the source of disruption: 3 minutes Time to initiate recovery: 5 minutes Time to monitor and restore capacities pre-crash: 8 minutes ### **Events of 2021 June 22 \(UTC\)** \(05:58 UTC\) | Initial onset of content delivery disruption \(05:58 UTC\) | Disruption identified by Swapcard monitoring \(06:03 UTC\) | Swapcard status post is activated \(06:05 UTC\) | Swapcard Engineering identified the issue \(06:08 UTC\) | Swapcard Engineering initiate the manual configuration change \(06:13 UTC\) | Impacted services began to recover \(06:16 UTC\) | Majority of services recovered, additional mitigation measures taken \(06:17 UTC\) | Incident Mitigated, pre-incident capacity restored \(06:23 UTC\) | Status post resolved Affected customers may have been impacted by varying degrees and with a shorter duration than as described above. ## **Forward Planning** Swapcard has deployed a permanent fix for this incident and implemented technical measures to ensure proper automatic maintenance windows on this endpoint and improve the primary/secondary hot switch configuration. In accordance with our high standard in terms of deliverability, Swapcard will conduct an internal audit on the hot switch capacity and configuration. Control are already in place but today’s incident highlights the need for improvement on this part. **We consider the likelihood of a recurrence of this issue to be extremely low and will further reduce the risk as we make future interventions and improvements to our infrastructure and procedures.**
A fix has been implemented and we are monitoring the results.
The issue has been identified and a fix is being implemented.