33 incident.io Status incidents · septembre 2025 — official updates, affected components, duration and resolution details.
État : résolu Cet incident a été résolu. Connexion via Slack fonctionne à nouveau normalement, et aucune autre action n'est requise. Composants touchés App Slack (opérationnel)
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Statut : Latence résolue est maintenant revenue à la normale. Entre 13h00 et 15h08 UTC il y avait des périodes de latence accrue de certaines API Microsoft. Les messages dans les équipes Microsoft ont été livrés avec une latence accrue. Notre tableau de bord et notre application mobile n'ont pas été touchés. Composants touchés Application Microsoft Teams (opérationnelle)
Traduit automatiquement depuis la mise à jour officielle de l'incident.
État : résolu Nous sommes maintenant retournés et les alertes d'inscription fonctionnent à nouveau normalement. Composants touchés Alerter l'ingestion, le traitement et la recherche (opérationnelle)
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Statut: Resolved Opsgenie webhook livraison retourné à la normale vers 17:48 BST composants touchés Opsgenie (opérationnel)
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Statut: Résolue Entre 00:00 et 02:44 UTC, certaines fonctionnalités AI ont retourné des taux d'erreur accrus. Nous assistons à un rétablissement complet. Composantes touchées Okta (opérationnel) Spunk (opérationnel) Téléphone (opérationnel) Jira (opérationnel) Google Docs (opérationnel) SMS (opérationnel) Splack (opérationnel) Application mobile (opérationnel) ClickUp (opérationnel) Zendesk (opérationnel) Alerter l'ingestion, le traitement et la pagination (opérationnel) Notifications (opérationnel) Cortex (opérationnel) Pages d'état (opérationnel) API (opérationnel) Confluence (opérationnel) GitHub (opérationnel) Azure DevOps (opérationnel) App Slack (opérationnel) Google Meet (opérationnel) Asana (opérationnel) Zapier (opérationnel) Zoom (opérationnel) Informations (opérationnel) Shortcut (opérationnel) OpsLevel (opérationnel) PagerDuty (opérationnel) Dashboard (opérationnel) Google Calendar (opérationnel) Email (opérationnel) Microsoft Teams app (opérationnel) Agent (opérationnel) Opsgenie (opérationnel) Datadog (opérationnel) Sent (opérational) Vanta (opérational Atlas)
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous sommes conscients des problèmes affectant certains clients se connecter à l'utilisation de SAML - nous enquêtons et fournirons une mise à jour sous peu.
Cette question demeure en cours et nous travaillons sur une résolution. Toutes les autres fonctionnalités ne sont pas affectées. Les sessions existantes sur l'application mobile et le tableau de bord ne sont pas affectées et continuent d'avoir un accès normal. Nous publierons notre prochaine mise à jour dans les 30 prochaines minutes.
Les connexions SAML travaillent maintenant avec une latence accrue. Nous continuerons à surveiller jusqu'à ce qu'il soit complètement récupéré. Toutes les autres fonctionnalités restent inchangées.
Nous continuons à voir des erreurs et des latences élevées avec les connexions SAML. Toutes les autres fonctionnalités restent inchangées.
Les connexions SAML fonctionnent désormais normalement. Nous continuerons de surveiller tout autre problème.
La connexion SAML a continué à fonctionner normalement.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous avons identifié une latence accrue et des délais qui affectent certaines demandes à notre tableau de bord. Les problèmes semblent transitoires et nous recommandons de les rafraîchir. Nous continuons d'enquêter.
Les taux de latence et d'erreur sont revenus à la normale. Nous continuons de surveiller tout autre problème.
Entre 19h31h30 et 19h34h30 UTC, certaines demandes à notre tableau de bord frappent des erreurs de latence et de connectivité accrues. La cause a été un incident de réseau en amont sur Google Cloud Platform. Les erreurs étaient transitoires et rafraîchissantes, généralement effacées. Les taux de latence et d'erreur sont de retour à la normale et on surveille les choses. Nous publierons un post mortem couvrant tout l'impact.
Nous avons observé une augmentation limitée de la latence ainsi qu'un petit nombre d'erreurs de tableau de bord entre 19:31:30 et 19:34:30 UTC. Cela a affecté 03% des appels à notre tableau de bord. Cela a été détecté par notre surveillance synthétique interne. La cause de ces erreurs élevées était due à des problèmes de réseautage au sein de GCP à l'époque. Cela est confirmé par nos journaux qui montrent que notre balanceur de charge GCP ne transmet pas de réponses réussies, ainsi que des time-outs réseau lorsqu'il essaie d'atteindre des services externes. L'impact a été limité à un petit nombre d'utilisateurs et a été résolu en rafraîchissant le tableau de bord.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous avons identifié des taux d'erreur accrus avec notre intégration Slack. Nous enquêtons actuellement sur l'impact que cela a sur notre plateforme - ce qui semble être un problème du côté de Slack, en particulier en ce qui concerne la création de canaux et la transmission de messages.
Slack a reconnu l'incident de leur côté. Vous pouvez suivre leur page d'état [ici](https://slack-status.com/2026-05/46d9d5d41fbedd9f).
Les taux d'erreur et la latence des opérations Slack sont revenus à la normale, et l'intégration s'est rétablie. Vous pouvez suivre les mises à jour sur la page d'état de Slack [ici](https://slack-status.com/2026-05/46d9d5d41fbedd9f).
Nous continuons à surveiller Slack en continuant à récupérer et ne voyons plus d'impact direct sur notre application Slack Vous pouvez suivre les mises à jour sur la page d'état de Slack [ici](https://slack-status.com/2026-05/46d9d5d41fbedd9f "ici").
Nous continuons de surveiller Slack en se rétablissant. Nous ne voyons aucun impact direct sur notre application Slack. Vous pouvez suivre les mises à jour sur la page d'état de Slack. [ici](https://slack-status.com/2026-05/46d9d5d41fbedd9f "ici").
Slack a confirmé que leurs services étaient largement revenus au niveau opérationnel. Nous n'avons pas vu d'impact direct sur notre application Slack depuis ~23:20 UTC hier. Nous résolvons cela de notre côté, et vous pouvez suivre d'autres mises à jour sur la page d'état de Slack-S [ici](https://slack-status.com/2026-05/46d9d5d41fbedd9f).
Traduit automatiquement depuis la mise à jour officielle de l'incident.
We have identified increased error rates with our Slack integration. We are currently investigating how this is impacting our platform - this seems to be an issue on the Slack side, particularly around channel creation.
We've confirmed the issue is relating to errors being returned by Slack. This is affecting a number of features of our integration, including: • Creating incident channels • Sending messages • Syncing Slack user groups Our web dashboard continues to be available and Scribe is unaffected.
Slack have acknowledged the incident on their side. You can follow their status page [here](https://slack-status.com/2026-05/fe557ca05fdb64fa).
We're continuing to monitor the situation - Slack have posted an update on their status page to confirm that they're working on it.
Le problème a été résolu du côté de Slack et nous avons confirmé que les choses nous semblent normales.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
The website is now up and working as normal.
The web dashboard is unavailable due to a JavaScript deployment issue.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous voyons des retards allant jusqu'à 30 minutes dans la réception de webhooks d'Opsgenie, ce qui peut retarder la livraison d'alerte. Nos systèmes fonctionnent normalement et traitent les alertes dès qu'elles arrivent; le problème semble être du côté Opsgenie. Nous suivons de près et partagerons les mises à jour au fur et à mesure que nous en apprendrons davantage.
Webhooks semble arriver comme normal à nouveau, de sorte que vous ne devriez plus voir de retards.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
We have identified increased error rates with our Atlassian Statuspage integration. Atlassian have published this to their status page [here](https://metastatuspage.com/incidents/94fwk40f4z15).
Error rates have returned to normal levels.
We have identified increased error rates coming from Microsoft Teams. We are currently investigating how this is impacting our platform and we will update with more information shortly as we learn more.
We have identified increased error rates coming from Microsoft Teams that are causing delays in sending messages to Teams channels and DMs. We'll continue to monitor the situation and we will update with more information shortly as we learn more. We will provide the next update by 1830 UTC.
We are continuing to see an increase in error rates from Microsoft Teams, causing a delay in sending some messages to Teams channels and DMs. We are monitoring the situation and will provide an update by 1930 UTC.
We have seen an improvement in error rates and latency for requests to Microsoft Teams, and we expect the performance of sending messages to Teams channels and DMs to have returned to normal. We are continuing to monitor to ensure performance remains as expected, and we will provide a further update by 2100 UTC.
We are no longer seeing elevated latency and error rates from Microsoft Teams.
We have identified increased error rates with an upstream call transcription provider. This is affecting Scribe for all customers. Our team are investigating and we will update with more information shortly as we learn more.
The issues were isolated to one region and we have performed a failover to a secondary region, restoring Scribe for all customers. You may need to ask Scribe to rejoin your call. We'll continue to monitor the situation and are working closely with the upstream provider while they resolve the issue.
Our failover region is continuing to work as expected, and Scribe functionality has been restored. You may need to ask Scribe to rejoin your calls. We'll continue to monitor the situation and are working closely with the upstream provider while they resolve the issue.
We continue to use the failover region, and Scribe performance has returned to expected levels.
We are currently investigating reports that users are unable to login using Slack.
Users in some Slack workspaces are unable to sign in with Slack. We have escalated this issue to Slack. Signing in with SAML and Microsoft Teams is not affected.
Slack have rolled back a change which caused this issue, and we have confirmed recovery. Please reach out to support if you're still experiencing any issues signing in with Slack.
Slack have confirmed that the issue has been fully resolved, and affected customers have verified that they can log in successfully.
We've identified a drop in inbound traffic to [incident.io](http://incident.io "incident.io") from Opsgenie. This means that alerts may be slow to show up in [incident.io](http://incident.io "incident.io"), and paging via Opsgenie may be slow to reflect updates. This appears to be an issue with outbound webhooks on Opsgenie's side, we're monitoring the situation and will update as we know more.
Traffic appears to be back to normal levels now.
We have identified increased error rates with our Atlassian Statuspage integration. Atlassian have acknowledged an issue on their side (<https://metastatuspage.com/incidents/ctw5xv6t643h>). We'll continue to monitor this until the issue is resolved.
Atlassian's status page continues to show the issue with Statuspage (<https://metastatuspage.com/incidents/ctw5xv6t643h>). To restore the integration you can follow Atlassian's recommended workaround to regenerate your API key and reconnect in incident.io. We'll continue to monitor this until the issue is resolved.
Atlassian's status page continues to show the issue with Statuspage (<https://metastatuspage.com/incidents/ctw5xv6t643h>). To restore the integration you can follow Atlassian's recommended workaround to regenerate your API key and reconnect in [incident.io.](http://incident.io./ "incident.io.") We'll continue to monitor this until the issue is resolved.
Atlassian's status page continues to show the issue with Statuspage (<https://metastatuspage.com/incidents/ctw5xv6t643h>). To restore the integration you can follow Atlassian's recommended workaround to regenerate your API key and reconnect in [incident.io.](http://incident.io./ "incident.io.") We'll continue to monitor this and give an update in the next hour.
Atlassian's status page now reports that they are rolling out a fix (<https://metastatuspage.com/incidents/ctw5xv6t643h>). In the meantime, to restore the integration you can follow Atlassian's recommended workaround to regenerate your API key and reconnect in [incident.io.](http://incident.io./ "incident.io.") We continue to monitor the issue until it is resolved.
Atlassian have confirmed that the issues with Statuspage have been resolved. You should now be able to reuse your original API key in our integration.
We have identified increased error rates with our Sentry integration. We are currently investigating how this is impacting our platform and we will update with more information shortly as we learn more.
Sentry have acknowledged an issue on their side ([https://status.sentry.io/incidents/wpg3tnwnwctj](https://status.sentry.io/incidents/wpg3tnwnwctj "https://status.sentry.io/incidents/wpg3tnwnwctj")), and we're seeing alerts come through from them ok. We'll continue to monitor things before closing this out.
We've not seen any errors from Sentry since 15:35 UTC so we're closing this out. Please see Sentry's status page for any further details.
We have identified an increased rate of Sentry integrations becoming disconnected. Alert ingestion is unaffected. Please don't uninstall our application from Sentry: we are working to restore these connections on our side, and no action is currently required. We will provide an update in 30 minutes.
We're currently testing the fix that will allow us to re-connect any disconnected Sentry integrations on behalf of customers, and will have another update on this in 30 minutes.
We've verified a fix locally, and we're starting to roll this out in production now.
We have confirmed that we are able to restore these connections, and we are now in the process of restoring these. When this happens, you'll see that the Sentry integration no longer flags up as requiring reconnection. Once we have finished restoring access, we'll post another update here.
We have managed to re-establish a connection to Sentry for almost all of the affected customers. If Sentry is still showing up as disconnected, you will need to remove the incident.io integration from the Sentry side, and then go through the reinstallation flow by opening incident.io and going to Settings → Integrations → Sentry. If you do this, please note that Sentry will remove the "Notify incident.io" action from alert rules when you uninstall the integration. If that was the only action in the alert rule, the entire rule is disabled. You will therefore need to verify any alert rules after re-installing.
We are aware of an issue that is causing delays updating data in Insights. The team are currently investigating, and we'll provide further updates soon.
We are aware of an issue that is causing delays updating data in Insights. The team are currently working on mitigating this, and we'll provide further updates soon.
The team have resolved this issue, and Insights are now syncing as expected.
