Historial de interrupciones de Swapcard

1. 9 de octubre de 2026 a las 12:30 UTCmonitoring

   Un retraso de replicación de datos en una de nuestras réplicas de bases de datos puede hacer que algunos usuarios vean información obsoleta o inconsistente en la interfaz. Algunos usuarios también pueden encontrarse con errores ocasionales. No se han perdido datos. Nuestro equipo ha tomado medidas, y estamos monitoreando de cerca mientras la réplica alcanza. Si ves inconsistencias, refresca la página. Publicaremos otra actualización una vez que esto esté completamente resuelto.

2. 9 de octubre de 2026 a las 15:04 UTCresolved

   El incidente está resuelto. La replicación está completamente de vuelta en sincronización, y la plataforma está funcionando normalmente.

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de octubre de 2026 a las 13:09 UTCresolved

   Entre las 03:00 y las 10:25 UTC, la API de desarrolladores puede haber devuelto errores intermitentes en algunas solicitudes. Las solicitudes que fallecieron durante esta ventana pueden ser recortadas con seguridad. El problema se ha resuelto y la API de desarrolladores está operando normalmente.

2. 7 de octubre de 2026 a las 13:09 UTCinvestigating

   Estamos investigando un problema donde la API de desarrolladores puede devolver errores intermitentes en algunas solicitudes. La mayoría de las solicitudes tienen éxito normalmente. Las solicitudes fallidas pueden ser recortadas con seguridad. Publicaremos una actualización tan pronto como tengamos más información.

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de octubre de 2026 a las 10:21 UTCinvestigating

   Actualmente estamos investigando un problema que afecta las notificaciones de empuje. Algunos usuarios pueden no recibir notificaciones de presión. Todas las otras características de la plataforma funcionan normalmente. Nuestro equipo está trabajando en una solución, y publicaremos una actualización aquí tan pronto como tengamos más información.

2. 7 de octubre de 2026 a las 10:31 UTCmonitoring

   Se ha aplicado una solución y se están entregando notificaciones de presión normalmente de nuevo. Estamos monitoreando para asegurarnos de que todo vuelva a la normalidad.

3. 7 de octubre de 2026 a las 11:45 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 11 de septiembre de 2026 a las 10:28 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 11 de septiembre de 2026 a las 10:29 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 8 de septiembre de 2026 a las 9:01 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

2. 8 de septiembre de 2026 a las 9:02 UTCmonitoring

   Se ha aplicado una solución. Estamos trabajando en restaurar los datos de análisis, no hay pérdida de datos durante el proceso.

3. 8 de septiembre de 2026 a las 9:04 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 31 de agosto de 2026 a las 18:52 UTCresolved

   El lunes 31 de agosto, los expositores y organizadores escanearon insignias comenzaron a ver un error después de un escaneo, con el escaneo luego almacenado como un escaneo sin conexión en el dispositivo. Esto sucedió en dispositivos con una conexión a Internet de trabajo, por lo que fue inicialmente equivocado para un problema de red de sede. En iOS, algunos dispositivos mostraron sólo una bandera roja que no se abrió cuando se tapped. **No se perdieron datos principales.** Dos mecanismos protegieron los datos al mismo tiempo. El lado del servidor, cada pista fue guardada en nuestra base de datos principal en el momento de la exploración, antes del paso que falló, por lo que el plomo ya existía incluso cuando la aplicación reportó un error. El lado del dispositivo, el modo offline de la aplicación captó el escaneo y lo sincronizaron una vez recuperado el escaneo. Debido a que una repetición de la misma exploración actualiza el plomo existente en lugar de agregar uno nuevo, esto no creó cables duplicados. La causa era específica para la ruta de exploración de placas. El registro, las páginas de eventos, las reuniones, la mensajería, las exportaciones y el organizador de back-office no se vieron afectados durante esta ventana.

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de julio de 2026 a las 17:37 UTCidentified

   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.

2. 1 de julio de 2026 a las 19:08 UTCidentified

   A fix to increase capacity is currently under testing.

3. 1 de julio de 2026 a las 19:48 UTCresolved

   Inference capacity has been fully restored

1. 19 de junio de 2026 a las 14:59 UTCidentified

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

2. 19 de junio de 2026 a las 15:00 UTCresolved

   This incident has been resolved.

3. 19 de junio de 2026 a las 15:35 UTCresolved

   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.

1. 19 de marzo de 2026 a las 13:07 UTCresolved

   This incident has been resolved.

2. 19 de marzo de 2026 a las 13:07 UTCresolved

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

1. 13 de marzo de 2026 a las 2:05 UTCresolved

   This incident has been resolved.

2. 13 de marzo de 2026 a las 3:05 UTCresolved

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

1. 11 de marzo de 2026 a las 14:33 UTCinvestigating

   We are currently investigating this issue.

2. 11 de marzo de 2026 a las 14:33 UTCmonitoring

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

3. 11 de marzo de 2026 a las 14:33 UTCresolved

   This incident has been resolved.

1. 11 de marzo de 2026 a las 14:33 UTCresolved

   This incident has been resolved.

1. 11 de marzo de 2026 a las 14:33 UTCidentified

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

2. 11 de marzo de 2026 a las 14:33 UTCresolved

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

3. 11 de marzo de 2026 a las 14:33 UTCresolved

   This incident has been resolved.

4. 11 de marzo de 2026 a las 14:33 UTCmonitoring

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

1. 11 de marzo de 2026 a las 14:33 UTCresolved

   This incident has been resolved.

1. 11 de marzo de 2026 a las 14:33 UTCresolved

   On Monday, January 17th at 15:30 UTC, we experienced an increase response time on our event app, the incident has lasted ~2min

1. 11 de marzo de 2026 a las 14:33 UTCresolved

   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.

1. 11 de marzo de 2026 a las 14:33 UTCresolved

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

2. 11 de marzo de 2026 a las 14:33 UTCresolved

   This incident has been resolved.

3. 11 de marzo de 2026 a las 14:33 UTCmonitoring

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

4. 11 de marzo de 2026 a las 14:33 UTCidentified

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

5. 11 de marzo de 2026 a las 14:33 UTCinvestigating

   We are currently investigating this issue.

1. 11 de marzo de 2026 a las 14:33 UTCresolved

   This incident has been resolved.

2. 11 de marzo de 2026 a las 14:33 UTCidentified

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

3. 11 de marzo de 2026 a las 14:33 UTCmonitoring

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

4. 11 de marzo de 2026 a las 14:33 UTCresolved

   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.

1. 11 de marzo de 2026 a las 14:33 UTCmonitoring

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

2. 11 de marzo de 2026 a las 14:33 UTCresolved

   This incident has been resolved.

3. 11 de marzo de 2026 a las 14:33 UTCresolved

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

4. 11 de marzo de 2026 a las 14:33 UTCinvestigating

   We are currently investigating this issue.

5. 11 de marzo de 2026 a las 14:33 UTCidentified

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

1. 11 de marzo de 2026 a las 14:33 UTCresolved

   This incident has been resolved.

2. 11 de marzo de 2026 a las 14:33 UTCresolved

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

3. 11 de marzo de 2026 a las 14:33 UTCmonitoring

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

4. 11 de marzo de 2026 a las 14:33 UTCidentified

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