Is Swapcard down?

Status: Investigating We are currently investigating this issue. Affected components Studio (Partial outage) Event App (Partial outage) Exhibitor Center (Partial outage)

Status: Resolved This incident has been resolved. Affected components Studio (Operational) Event App (Operational) Exhibitor Center (Operational)

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

Status: Monitoring A fix has been implemented. We are working on restoring the analytics data, there are no data loss during the process.

Status: Resolved This incident has been resolved.

Status: Resolved On Monday 31 August, exhibitors and organizers scanning badges began seeing an error after a scan, with the scan then stored as an offline scan on the device. This happened on devices with a working internet connection, which is why it was initially mistaken for a venue network problem. On iOS, some devices showed only a red banner that did not open when tapped. No lead data was lost. Two mechanisms protected the data at the same time. Server side, each lead was saved to our primary database at the moment of the scan, before the step that failed, so the lead already existed even when the app reported an error. Device side, the app's offline mode captured the scan and synced it once scanning recovered. Because a repeat submission of the same scan updates the existing lead rather than adding a new one, this did not create duplicate leads. The cause was specific to the badge scanning path. Registration, event pages, meetings, messaging, exports and the organizer back-office were not affected during this window.

Status: Identified 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.

Status: Identified A fix to increase capacity is currently under testing.

Status: Resolved Inference capacity has been fully restored

Status: Identified The issue has been identified and a fix is being implemented. Affected components Login (Partial outage)

Status: Resolved This incident has been resolved. Affected components Login (Operational)

Status: 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. Affected components Login (Operational)