AdGuard Outage History

Started Dec 19, 2025, 04:49 PM UTC· resolved Dec 19, 2025, 09:08 PM UTC

1. investigating Dec 19, 2025, 04:49 PM UTC

   We’re investigating global connectivity issues affecting multiple regions and causing degraded service performance.

2. resolved Dec 19, 2025, 09:08 PM UTC

   The incident has been resolved

Read the full incident report →

Started Dec 02, 2025, 09:23 AM UTC· resolved Dec 02, 2025, 09:58 AM UTC

1. monitoring Dec 02, 2025, 09:23 AM UTC

   Fix was already implemented. Service is restoring right now. We are monitoring the situation.

2. resolved Dec 02, 2025, 09:58 AM UTC

   This incident has been resolved.

3. postmortem Dec 10, 2025, 01:07 PM UTC

   Read our [blog](https://adguard-vpn.com/en/blog/redis-kubernetes-vpn-incident-post-mortem.html) to see what happened

Read the full incident report →

Started Nov 25, 2025, 03:52 PM UTC· resolved Nov 25, 2025, 05:59 PM UTC

1. investigating Nov 25, 2025, 03:52 PM UTC

   We're currently investigating the issue

2. identified Nov 25, 2025, 05:18 PM UTC

   The issue is identified. We are applying the fix to restore the service.

3. resolved Nov 25, 2025, 05:59 PM UTC

   The issue has been resolved. We will continue to monitor the situation and will provide a more detailed update regarding the causes of the incident at a later date.

4. postmortem Dec 02, 2025, 10:19 AM UTC

   You can find more technical details about this incident in [our blog](https://adguard-dns.io/en/blog/partial-adguard-dns-outage-11-25.html)

Read the full incident report →

Started Nov 19, 2025, 02:14 PM UTC· resolved Nov 19, 2025, 03:19 PM UTC

1. investigating Nov 19, 2025, 02:14 PM UTC

   We are currently observing connectivity issues affecting AdGuard DNS servers in Singapore. We are working to identify and mitigate the issue.

2. identified Nov 19, 2025, 02:58 PM UTC

   Issue was identified. We are currently working on service restore.

3. identified Nov 19, 2025, 03:05 PM UTC

   Fix was implemented, we're monitoring now

4. resolved Nov 19, 2025, 03:19 PM UTC

   Issue was resolved

Read the full incident report →

Started Nov 18, 2025, 11:41 AM UTC· resolved Nov 19, 2025, 07:08 AM UTC

1. investigating Nov 18, 2025, 11:41 AM UTC

   We’re experiencing an outage affecting access to the site from EU region. The issue originates from an upstream network provider, causing intermittent failures and timeouts. Our systems are operating normally, but external connectivity is degraded. We’re monitoring the situation and will restore full availability as soon as the upstream provider resolves the problem.

2. monitoring Nov 18, 2025, 03:05 PM UTC

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

3. resolved Nov 19, 2025, 07:08 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 30, 2025, 08:55 PM UTC· resolved Oct 30, 2025, 10:50 PM UTC

1. investigating Oct 30, 2025, 08:55 PM UTC

   We are currently observing connectivity issues affecting AdGuard DNS in Miami, FL and working to mitigate the issue

2. resolved Oct 30, 2025, 10:50 PM UTC

   This Incident has been resolved

Read the full incident report →

Started Oct 09, 2025, 08:10 AM UTC· resolved Oct 09, 2025, 08:53 AM UTC

1. investigating Oct 09, 2025, 08:10 AM UTC

   We’re performing a hardware upgrade on our servers in Johannesburg. All traffic is temporarily rerouted to our European points of presence, which may slightly increase latency for users in the African region over the next 60 minutes.

2. identified Oct 09, 2025, 08:12 AM UTC

   We’ve started a hardware upgrade.

3. resolved Oct 09, 2025, 08:53 AM UTC

   This Incident has been resolved

Read the full incident report →

Started Oct 04, 2025, 09:59 AM UTC· resolved Oct 04, 2025, 10:54 AM UTC

1. investigating Oct 04, 2025, 09:59 AM UTC

   We are currently observing connectivity issues affecting AdGuard DNS in the Southeast Asia region. The disruption is caused by network problems among several backbone providers operating in the area.

2. investigating Oct 04, 2025, 10:09 AM UTC

   We are continuing to investigate this issue.

3. identified Oct 04, 2025, 10:34 AM UTC

   According to our monitoring, the issue has been resolved, but we continue to observe the situation.

4. resolved Oct 04, 2025, 10:54 AM UTC

   This Incident has been resolved

Read the full incident report →

Started Sep 24, 2025, 07:45 PM UTC· resolved Sep 24, 2025, 09:36 PM UTC

1. investigating Sep 24, 2025, 07:45 PM UTC

   We are performing scheduled hardware upgrades on our servers in Chicago. We do not anticipate any outages, but as a precaution, part of the IPv4 traffic will be rerouted through other North American locations.

2. identified Sep 24, 2025, 08:01 PM UTC

   We're currently performing hardware upgrade

3. resolved Sep 24, 2025, 09:36 PM UTC

   This Incident has been resolved

Read the full incident report →

Started Sep 24, 2025, 06:43 AM UTC· resolved Sep 24, 2025, 07:40 PM UTC

1. investigating Sep 24, 2025, 06:43 AM UTC

   We're currently investigating the issue which causes a severe delay in query log updates in private AdGuard DNS service. We presume that no logs have been lost, and they will arrive when the issue is solved.

2. identified Sep 24, 2025, 08:04 AM UTC

   The issue has been identified, currently restoring missing query logs.

3. identified Sep 24, 2025, 09:16 AM UTC

   At this moment we can confirm the following: * No query logs were missed * Some query logs for 23.09.2025 are delivered twice - we will implement the fix today * Some old and new logs are shown in control panel with significant delay - we await resolving in the next 2-3 hours

4. identified Sep 24, 2025, 10:21 AM UTC

   All missing logs are now visible in UI. We are working on a deduplication of 23.09.2025 logs

5. identified Sep 24, 2025, 12:55 PM UTC

   All logs for 23.09.2025 will be refilled

6. identified Sep 24, 2025, 02:03 PM UTC

   All missing logs will become visible in the next 90 minutes

7. monitoring Sep 24, 2025, 04:39 PM UTC

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

8. resolved Sep 24, 2025, 07:40 PM UTC

   This incident has been resolved. We will add postmortem soon

Read the full incident report →

Started Aug 26, 2025, 06:48 AM UTC· resolved Aug 26, 2025, 08:14 AM UTC

1. identified Aug 26, 2025, 06:48 AM UTC

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

2. identified Aug 26, 2025, 07:27 AM UTC

   We are continuing to work on a fix for this issue.

3. monitoring Aug 26, 2025, 07:42 AM UTC

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

4. resolved Aug 26, 2025, 08:14 AM UTC

   This incident has been resolved.

5. postmortem Aug 27, 2025, 10:22 AM UTC

   At 05:00 \(UTC\) on August 26, due to routing changes in tier-1 backbone providers’ networks, a huge amount of traffic to AdGuard DNS from across Europe began to be routed to our Istanbul location \(instead of the usual Frankfurt, London, and Amsterdam\). Unfortunately, the Istanbul PoP is not capable of handling such a massive volume of traffic, as it normally only serves users from the Middle East. However, instead of a complete outage \(which we would have noticed immediately\), overload protection mechanisms only started limiting user connections. This led to an “accumulation” of unresolved DNS queries on user devices. Because of this, we only discovered the incident at 06:30 and manually disabled the Istanbul location. Immediately afterward, all accumulated user queries from the previous hour and a half were redirected to the more powerful Frankfurt PoP. Processing this backlog took about an hour, during which users could have experienced significant delays in DNS resolution. All issues were finally resolved at 08:30 As a result of this incident, we decided to: * Increase the number of servers in Istanbul to handle potential traffic spikes * Distribute European traffic across multiple PoPs so that none of them becomes a single point of failure * Improve our monitoring system to detect routing issues more quickly and respond faster

Read the full incident report →

Started Jul 11, 2025, 11:52 AM UTC· resolved Jul 11, 2025, 01:43 PM UTC

1. investigating Jul 11, 2025, 11:52 AM UTC

   We are currently investigating a network issue that is causing degraded availability of our websites, AdGuard VPN, and AdGuard DNS.

2. identified Jul 11, 2025, 12:11 PM UTC

   We've identified the issue, and currently are implementing the fix.

3. monitoring Jul 11, 2025, 01:09 PM UTC

   The fix has been applied successfully. We've currently monitoring our services for any lingering impact.

4. monitoring Jul 11, 2025, 01:09 PM UTC

   We are continuing to monitor for any further issues.

5. resolved Jul 11, 2025, 01:43 PM UTC

   This incident has been resolved.

6. postmortem Jul 11, 2025, 01:44 PM UTC

   **Summary** Our internal infrastructure experienced approximately one hour of degraded availability due to a failure in our network edge. One of our upstream provider’s routers in the datacenter became unreachable. As a result, one of our two edge routers lost upstream connectivity. While this is a relatively common failure scenario — and one we are explicitly architected to tolerate — our redundancy mechanism did not operate as expected. **Architecture Overview** Our edge routing stack is designed for high availability. It consists of two physical routers configured to act as a single logical gateway using a shared IP address. From the perspective of connected systems, this setup \(often referred to as MLAG-style L3 redundancy or a "virtual router"\) appears as a single device. Inbound traffic is typically distributed across both routers based on hashing \(ECMP or per-flow load balancing\), and under normal circumstances, either router can forward traffic upstream. **What Went Wrong** When one of the upstream links failed:The affected router remained active in the logical group and continued accepting traffic. The hash-based forwarding mechanism continued to assign flows to both routers, including the one that had no upstream connectivity. As a result, approximately half of the traffic was routed to a black hole — silently dropped by the router with no upstream. This manifested externally as intermittent availability — services appeared "flaky" or unreachable in ~50% of cases depending on which path the packet was hashed to. **Mitigation** The immediate resolution involved manually removing the non-functional router from the logical group. This is a non-trivial operation, as simply powering down the router can have unintended side effects. The process took longer than expected due to its operational complexity. Once the faulty node was excluded, all traffic was successfully routed through the healthy router, and services stabilized. **Next Steps** We are currently investigating why automatic failover did not trigger as expected. Our routers are designed to detect upstream failures and withdraw from the logical group accordingly, but that mechanism failed silently. As a follow-up, we will: * Reproduce the failure scenario in a controlled environment * Validate and adjust failover and tracking logic * Improve observability for edge failover behavior * Develop faster manual intervention playbooks

Read the full incident report →

Started Jul 09, 2025, 05:06 PM UTC· resolved Jul 09, 2025, 07:16 PM UTC

1. identified Jul 09, 2025, 05:06 PM UTC

   We are currently experiencing a delay in the display of DNS query logs. DNS resolution itself is fully operational and unaffected — this issue does not impact filtering or performance. Our team is working on resolving the problem.

2. resolved Jul 09, 2025, 07:16 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 24, 2025, 06:09 PM UTC· resolved Jun 24, 2025, 08:46 PM UTC

1. investigating Jun 24, 2025, 06:09 PM UTC

   We're currently investigating the issue of some DNS query logs not being visible on the dashboard and query log page for some clients.

2. investigating Jun 24, 2025, 06:41 PM UTC

   While the investigation is still ongoing, we're confident that no query logs are lost, and they are currently appearing on client's dashboard and query logs page with a delay of approximately 30 minutes.

3. resolved Jun 24, 2025, 08:46 PM UTC

   The issue has been resolved. All missing queue logs should now be visible on the query log page, and all stats on the dashboard should match accordingly

Read the full incident report →

Started Jun 11, 2025, 11:14 PM UTC· resolved Jun 11, 2025, 11:53 PM UTC

1. investigating Jun 11, 2025, 11:14 PM UTC

   We are currently investigating this issue.

2. identified Jun 11, 2025, 11:43 PM UTC

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

3. resolved Jun 11, 2025, 11:53 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 27, 2025, 11:00 AM UTC· resolved May 27, 2025, 01:00 PM UTC

1. resolved May 28, 2025, 10:11 AM UTC

   Due to internal services misconfiguration AdGuard websites was partially unavailable for some users during ~2 hours. All problems are solved now; we'll add postmortem about this situation later.

Read the full incident report →

Started May 22, 2025, 01:00 AM UTC· resolved May 22, 2025, 01:00 AM UTC

1. resolved May 22, 2025, 01:50 PM UTC

   Due to an overwhelming number of requests to our authentication backend at the time, an internal issue occurred that temporarily disrupted its performance, which resulted in its partial unavailability. A permanent fix is in works, and in the meantime we're implementing a temporary solution to keep the backend operational. We would like to apologize for the inconvenience.

Read the full incident report →

Started May 16, 2025, 02:33 PM UTC· resolved May 16, 2025, 05:34 PM UTC

1. investigating May 16, 2025, 02:33 PM UTC

   AdGuard website is currently under a DDoS attack and may be experiencing slow performance. Judging by the nature of the attack, the attacker is very unhappy that AdGuard blocks ads on movie websites (likely pirated ones), as we initially observed millions of HTTP requests like: “StopUpdatingRulesForMoviesWebsites=stopedtingformovieswebsites@gmail.com” Naturally, we will continue blocking ads on such sites — and we’ll strive to do it even more quickly and effectively than before (if that’s even possible).

2. identified May 16, 2025, 02:50 PM UTC

   We're deploying anti-DDOS measures. By the way, this is a great moment to remind everyone that AdGuard filters are among the most popular and actively maintained in the world. They’re developed with the help of a large and passionate community, and we welcome any and all contributions. You can suggest your own filtering rules or let us know where ads are still slipping through. Learn more in our filter repository: 👉 https://github.com/AdguardTeam/AdGuardFilters The real strength of ad blockers lies in the community — it’s the result of the work of thousands of people. Huge thanks to everyone who’s helping make the web cleaner.

3. resolved May 16, 2025, 05:34 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 15, 2025, 11:00 PM UTC· resolved May 15, 2025, 11:00 PM UTC

1. resolved May 16, 2025, 11:36 AM UTC

   Last night, the AdGuard website was subjected to a massive DDoS attack. Our team took all necessary actions to mitigate the situation. As part of the mitigation process, we enabled a manual anti-DDoS mode based on a set of predefined rules. Unfortunately, at this stage, a misconfiguration occurred: an overly broad rule was deployed, which disrupted connectivity to our payment gateway. As a result, for approximately 5.5 hours, information about completed purchases was not reaching AdGuard. This led to a failure to issue new licenses and activation keys. At the time of writing, the issue has been fully resolved. All payments made during the affected time window should now be processed correctly. If you are still experiencing any issues, please contact us at [email protected] — we will do our best to help you as quickly as possible. To prevent such incidents in the future, we will take the following steps: * Decouple payment processing logic from other systems * Avoid using overly broad anti-DDoS rules * Apply new rules with greater scrutiny and caution

Read the full incident report →

Started Mar 16, 2025, 04:19 PM UTC· resolved Mar 16, 2025, 05:19 PM UTC

1. investigating Mar 16, 2025, 04:19 PM UTC

   We are currently investigating this issue.

2. identified Mar 16, 2025, 04:36 PM UTC

   AdGuard DNS core provider is migrating its infrastructure right now. We're monitoring this situation

3. resolved Mar 16, 2025, 05:19 PM UTC

   This incident has been resolved.

Read the full incident report →