Istoricul incidentelor Swapcard

1. 9 octombrie 2026 la 12:30 UTCmonitoring

   O întârziere de replicare a datelor pe una dintre reproducerile bazei noastre de date poate determina unii utilizatori să vadă informații depășite sau inconsecvente în interfață. Unii utilizatori pot, de asemenea, rula în erori ocazionale. Nu s-au pierdut date. Echipa noastră a luat măsuri şi monitorizăm îndeaproape în timp ce replica prinde din urmă. Dacă vezi neconcordanţe, împrospătează pagina. Vom posta o altă actualizare odată ce acest lucru este complet rezolvat.

2. 9 octombrie 2026 la 15:04 UTCresolved

   Incidentul este rezolvat. Replica este complet sincronizată, iar platforma funcţionează normal.

Traducere automată din actualizarea oficială a incidentului.

1. 7 octombrie 2026 la 13:09 UTCresolved

   Între 03:00 și 10:25 UTC, API Dezvoltator poate fi returnat erori intermitente la unele cereri. Solicitările care au eșuat în timpul acestei ferestre pot fi rejudecate în siguranță. Problema a fost rezolvată, iar API-ul Dezvoltatorului funcționează normal.

2. 7 octombrie 2026 la 13:09 UTCinvestigating

   Investigăm o problemă în care API-ul Dezvoltatorului poate returna erori intermitente la unele cereri. Majoritatea cererilor reuşesc în mod normal. Cererile eșuate pot fi rejudecate în siguranță. Vom posta o actualizare de îndată ce vom avea mai multe informații.

Traducere automată din actualizarea oficială a incidentului.

1. 7 octombrie 2026 la 10:21 UTCinvestigating

   Investigăm în prezent o problemă care afectează notificările de împingere. Unii utilizatori nu pot primi notificări de împingere. Toate celelalte caracteristici ale platformei funcţionează normal. Echipa noastră lucrează la un fix, și vom posta o actualizare aici de îndată ce avem mai multe informații.

2. 7 octombrie 2026 la 10:31 UTCmonitoring

   A fost aplicat un fix și notificările de împingere sunt livrate din nou în mod normal. Monitorizăm pentru a ne asigura că totul a revenit la normal.

3. 7 octombrie 2026 la 11:45 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 11 septembrie 2026 la 10:28 UTCinvestigating

   În prezent investigăm această problemă.

2. 11 septembrie 2026 la 10:29 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 8 septembrie 2026 la 09:01 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

2. 8 septembrie 2026 la 09:02 UTCmonitoring

   A fost implementată o soluţie. Lucrăm la restabilirea datelor de analiză, nu există pierderi de date în timpul procesului.

3. 8 septembrie 2026 la 09:04 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 31 august 2026 la 18:52 UTCresolved

   Luni, 31 august, expozanţii şi organizatorii au început să scaneze insignele şi au văzut o eroare după o scanare, iar scanarea a fost apoi păstrată ca o scanare offline pe dispozitiv. Acest lucru sa întâmplat pe dispozitive cu o conexiune la internet de lucru, motiv pentru care a fost inițial confundat cu o problemă de rețea locatie. Pe iOS, unele dispozitive au arătat doar un banner roșu care nu se deschidea atunci când a fost exploatat. **Nu s-au pierdut date despre plumb.** Două mecanisme au protejat datele în același timp. Parte server, fiecare plumb a fost salvat în baza noastră de date primară în momentul scanării, înainte de pasul care a eșuat, astfel încât plumbul a existat deja chiar și atunci când aplicația a raportat o eroare. Latura dispozitivului, modul offline al aplicației a surprins scanarea și a sincronizat-o odată ce scanarea a fost recuperată. Deoarece o depunere repetată a acelorași scanări actualizează plumbul existent în loc să adauge unul nou, acest lucru nu a creat piste duplicate. Cauza a fost specifică căii de scanare a insignei. Înregistrarea, paginile de evenimente, întâlnirile, mesageria, exporturile și biroul organizatorului nu au fost afectate în timpul acestei ferestre.

Traducere automată din actualizarea oficială a incidentului.

1. 1 iulie 2026 la 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 iulie 2026 la 19:08 UTCidentified

   A fix to increase capacity is currently under testing.

3. 1 iulie 2026 la 19:48 UTCresolved

   Inference capacity has been fully restored

1. 19 iunie 2026 la 14:59 UTCidentified

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

2. 19 iunie 2026 la 15:00 UTCresolved

   This incident has been resolved.

3. 19 iunie 2026 la 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 martie 2026 la 13:07 UTCresolved

   This incident has been resolved.

2. 19 martie 2026 la 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 martie 2026 la 02:05 UTCresolved

   This incident has been resolved.

2. 13 martie 2026 la 03: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 martie 2026 la 14:33 UTCinvestigating

   We are currently investigating this issue.

2. 11 martie 2026 la 14:33 UTCmonitoring

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

3. 11 martie 2026 la 14:33 UTCresolved

   This incident has been resolved.

1. 11 martie 2026 la 14:33 UTCresolved

   This incident has been resolved.

1. 11 martie 2026 la 14:33 UTCidentified

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

2. 11 martie 2026 la 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 martie 2026 la 14:33 UTCresolved

   This incident has been resolved.

4. 11 martie 2026 la 14:33 UTCmonitoring

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

1. 11 martie 2026 la 14:33 UTCresolved

   This incident has been resolved.

1. 11 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 14:33 UTCresolved

   This incident has been resolved.

3. 11 martie 2026 la 14:33 UTCmonitoring

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

4. 11 martie 2026 la 14:33 UTCidentified

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

5. 11 martie 2026 la 14:33 UTCinvestigating

   We are currently investigating this issue.

1. 11 martie 2026 la 14:33 UTCresolved

   This incident has been resolved.

2. 11 martie 2026 la 14:33 UTCidentified

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

3. 11 martie 2026 la 14:33 UTCmonitoring

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

4. 11 martie 2026 la 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 martie 2026 la 14:33 UTCmonitoring

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

2. 11 martie 2026 la 14:33 UTCresolved

   This incident has been resolved.

3. 11 martie 2026 la 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 martie 2026 la 14:33 UTCinvestigating

   We are currently investigating this issue.

5. 11 martie 2026 la 14:33 UTCidentified

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

1. 11 martie 2026 la 14:33 UTCresolved

   This incident has been resolved.

2. 11 martie 2026 la 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 martie 2026 la 14:33 UTCmonitoring

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

4. 11 martie 2026 la 14:33 UTCidentified

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