Ingrid experienced a critical incident on January 26, 2026 affecting Checkout and Transport Administration and 1 more component, lasting 4d 2h. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating Jan 26, 2026, 07:51 AM UTC
We have recently identified an error in the system that affects Ingrid Services. We are currently investigating this with the highest priority and we will be updating you with the status of the investigation and resolution of this issue through this channel. We apologize for the inconvenience in the meantime and ask for your continued patience as we work on resolving this matter.
- investigating Jan 26, 2026, 08:04 AM UTC
Prio: Critical Scope: Ingrid Services Update: The issue has been identified as DNS server connection issues causing Ingrid Services to be unavailable. We are continuing to monitor the situation and we will give updates here as we receive more information
- monitoring Jan 26, 2026, 08:09 AM UTC
The error appears to have been resolved. We are currently monitoring the fix and we will update here as we confirm the resolution of this incident.
- resolved Jan 30, 2026, 10:15 AM UTC
This incident was resolved since 26th of January at 09:09. Closing this now to provide post mortem information.
- postmortem Jan 30, 2026, 10:15 AM UTC
### Summary On Monday, 26 January 2026, Ingrid experienced intermittent connectivity issues affecting access to Ingrid services and APIs. The disruption was caused by an incorrect DNS configuration and resulted in a portion of inbound traffic failing to reach Ingrid during the incident window. The impact grew gradually due to standard DNS caching behavior across networks and providers. At peak, Ingrid estimates that up to ~25% of inbound requests were affected between 07:30 and 09:10 CET. ### Customer Impact **Affected services:** Ingrid platform and APIs \(general connectivity\) **What customers experienced:** * Intermittent inability to reach Ingrid services * Increased request failures/timeouts for a subset of users **Impact window \(CET\):** * **Start:** 07:30 * **Fix implemented:** 09:00 * **Recovery confirmed:** 09:10 * **Peak impact:** up to ~25% of inbound requests affected \(gradual increase over time\) **Note on DNS caching:** After the correction, recovery began immediately. Depending on the DNS resolver and caching behavior used by a customer’s network/ISP, some users may have experienced residual intermittent issues for a limited period after 09:10 CET. ### What Happened DNS determines how clients locate Ingrid’s services. During routine configuration activity, Ingrid’s DNS name server settings were unintentionally changed. This led some DNS queries to be answered incorrectly, preventing certain clients from reaching Ingrid. Because DNS settings are cached across the internet and refreshed over time, the impact increased gradually as cached records expired and were re-queried. ### Timeline \(CET\) * **07:30** — Incorrect DNS configuration introduced. * **07:40** — Initial internal signal of connectivity issues observed. * **08:02** — Multiple customer reports received and investigation initiated. * **08:45** — Incident declared as critical. * **09:00** — Root cause identified and DNS configuration corrected. * **09:10** — Recovery confirmed; inbound traffic returned to normal levels. ### Root Cause An incorrect configuration of Ingrid’s DNS name server settings caused a subset of DNS queries to be directed to name servers that could not correctly resolve Ingrid’s domain, resulting in intermittent connectivity failures. ### Resolution Ingrid reverted the incorrect DNS configuration. Service recovery began immediately after the correction and normal traffic levels were confirmed within approximately 10 minutes. Some customers may have experienced residual impact beyond this point due to external DNS caching. ### Preventive Actions Ingrid is implementing the following improvements to reduce recurrence risk and improve detection: **Monitoring and early detection** * Monitoring and alerting for sensitive DNS record changes * Traffic-volume anomaly alerts to detect partial connectivity degradation earlier **Testing coverage** * Expanded synthetic monitoring coverage using multiple locations and DNS resolvers to reduce reliance on cached DNS paths **Change management** * Strengthened risk assessment and operational controls for high-impact infrastructure changes