AudioEye Outage History

AudioEye is up right now

AudioEye had 4 outages in the last 2 years totaling 15h 22m of downtime — averaging 0.2 incidents per month.

There were 4 AudioEye outages since February 27, 2026 totaling 15h 22m of downtime. Each is summarised below — incident details, duration, and resolution information.

Source: https://status.audioeye.com

Notice May 5, 2026

Historical Reporting Data Temporarily Unavailable

Detected by Pingoru
May 05, 2026, 11:42 PM UTC
Resolved
May 06, 2026, 03:05 PM UTC
Duration
15h 22m
Timeline · 2 updates
  1. identified May 05, 2026, 11:42 PM UTC

    We are aware of an issue affecting historical reporting data in our Trends (Beta) feature and are actively working to restore it. This does not affect live site scanning or accessibility monitoring. We will post updates as restoration progresses.

  2. resolved May 06, 2026, 03:05 PM UTC

    The historical reporting data used in the Trends (Beta) feature has been restored.

Read the full incident report →

Notice May 2, 2026

Brief DNS Disruption on Aegis Domains During Springtime Migration

Detected by Pingoru
May 02, 2026, 03:57 AM UTC
Resolved
May 01, 2026, 05:30 PM UTC
Duration
Timeline · 1 update
  1. resolved May 02, 2026, 03:57 AM UTC

    During a planned migration of the Springtime CMP toolbar to new infrastructure, the aegis.audioeye.com and aegis.audioeye-services.com domains experienced approximately 4 minutes of DNS unavailability while DNS records were manually transferred to a new Cloudflare Pages deployment. Service was restored once the DNS update completed, and no further impact was observed.

Read the full incident report →

Notice March 20, 2026

Degradation of Audioeye Services

Detected by Pingoru
Mar 20, 2026, 06:25 PM UTC
Resolved
Mar 20, 2026, 06:25 PM UTC
Duration
Affected: AudioEye Services
Timeline · 1 update
  1. resolved Mar 20, 2026, 06:25 PM UTC

    During a scheduled deployment of CDN rules, we unintentionally triggered a cache purge. The resulting traffic spike overwhelmed our backend systems, causing server errors for approximately 0.5% of requests between 17:56–18:04 UTC. Our on-call team detected the issue within minutes and restored capacity by scaling backend resources.

Read the full incident report →