17 Instabug incidents · mars 2022 — official updates, affected components, duration and resolution details.
Taux d'erreur élevés sur le tableau de bord
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
À partir de 13h00 UTC le 7 juillet 2026, certains clients ont peut-être connu des temps de charge plus lents et des retards dans les données apparaissant sur leurs tableaux de bord. Nous avons tracé la cause de l'augmentation de la charge sur une partie de notre infrastructure de base et avons appliqué des mesures d'atténuation, y compris l'échelle des systèmes touchés. Le rendement des services s'est largement rétabli. Nous surveillons activement la situation et mettons en place des mesures de protection supplémentaires pour éviter que cela ne se reproduise. Nous publierons d'autres mises à jour dès qu'elles seront disponibles.
Les réparations ont été effectuées et l'incident a été résolu.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
We're currently experiencing delays in processing and displaying some incoming data. New crash reports, performance monitoring metrics (app launches, network requests, traces, and screen visits), and session analytics may appear with a lag or be temporarily incomplete in your dashboards. Our engineering team has identified the cause and is actively working to restore normal processing speeds. No data is being lost. Affected information will be processed and appear once the backlog clears.
We are continuing to work on a fix for this issue.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
Affected: APM, Dashboard, Crashes, Chats, Surveys Start: June 4, 2026 at 10:56 UTC Resolved:June 4, 2026 at 11:08 UTC Some users experienced intermittent issues with SDK data ingestion and dashboard access during this window. The team identified the issue and restored capacity. All services are now operating normally.
There is an issue with ingesting the data into our databases, we are currently working on a fix, it has been down for the past 1.5 hours. No data loss is expected
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
we experienced an unexpected outage lasting around 40 minutes, causing partial unavailability and degraded performance across core services. Systems were restored after mitigation steps, and services are now operating normally.
Earlier today, AWS had operational issues with no effect on our APIs & Dashboards https://health.aws.amazon.com/health/status We've just started experiencing throttling to some of our infrastructure on AWS that are degrading our services
All systems are operational
No new events being ingested
The issue has been identified and a fix is being implemented.
Dashboard is up and running
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
Dashboard is unstable due to configuration issues
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
We are continuing to monitor for any further issues.
This incident has been resolved.
1/6/2025 4:50pm GMT: Certain crash reporting pages are experiencing performance issues or delays. Investigation started
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
12:00pm GMT: Part of the sessions processing for counts went down -for legacy versions of the SDK-. We're working on restoring it. 1:47pm GMT: Issue fixed, and new sessions are being processed normally.
3:15pm GMT: Facing delays in processing new sessions, Investigating the issue 4:20pm GMT: Issue fixed, and processing rates restored. No data loss and no backlog
2:30am GMT: Facing delays in processing crashes and non-fatals. Investigating the issue 8:40am GMT: Issue fixed, and processing rates restored. No data loss, but seeing some delays
Location data on user sessions is incorrectly shown as originating from the United States instead of the end user's location. This was caused due to a misconfiguration on Instabug's infrastructure and was resolved once detected.
We are currently investigating this issue.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
The Crashes dashboard is not rendering properly for customers. We are aware of the issue and working to promptly resolve it. This does not impact any private-cluster customers.
This issue has been identified and confirmed to be caused by a deployment by our cloud provider. A restore is currently in progress
Restore is done. Issue should be now resolved. We're monitoring to make sure everything is working as expected
This incident has been resolved.
## Summary On April 18th, 2022, between 13:36 UTC and 14:30 UTC, Instabug experienced an operational incident that caused some crashes to not be accessible. During this time, no crashes or occurrences were lost or dropped. This issue only impacted viewing of crashes, and our APIs were not impacted in any way. ## What Happened Amazon Web Services \(AWS\) was performing a blue/green deployment while services underlying Instabug’s infrastructure. During this deployment, several of the indices associated with our Elasticsearch database were incorrectly deleted. Once the issue was discovered, Instabug engineers contacted AWS support who acknowledged the issue and restored the indices from a snapshot. Upon restoration, services were fully functional. ## What We Are Doing About This AWS has committed to notifying us before any release or migration that may impact our services.
A server-side configuration change was rolled out that resulted in our SDK crashing when caching the response of server-side payload. Since the aforementioned API request happens right after the app has finished launching, this resulted in apps using the Instabug SDK crashing right after they launch. We were alerted about this issue as soon as it started happening and we quickly changed the configuration that caused the crash. In total, it took around 40 minutes from the first alert we got till the fix rolled out to 100% of the applications using our SDK. There is no action required from your side related to this crash.
