Historique des pannes de Lever

1. 26 août 2026 à 16:24 UTCresolved

   Vers 8 h 30 UTC le 25 mai 2026, une rotation programmée du serveur à l'adresse https://hire.eulever.co/ a entraîné une augmentation de la latence et certaines pages ont échoué jusqu'à 9 h 15 UTC. Les utilisateurs touchés remarqueraient une erreur "504" pendant les chargements de page touchés. Le service a été rendu à tous les utilisateurs à partir de 9h15 UTC le 25/08/2026. Une ACR complète sera affichée sur ce numéro dans les 7 à 10 jours ouvrables.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 août 2026 à 20:12 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 21 août 2026 à 20:29 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 24 août 2026 à 14:16 UTCresolved

   État : résolu Notre surveillance a confirmé qu'il n'y avait pas d'autres problèmes liés à cet incident. Le service est demeuré stable et l'incident est maintenant considéré comme résolu. Une analyse des causes profondes sera fournie dans les 7-10 jours ouvrables.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 12 août 2026 à 18:13 UTCresolved

   Vers 10:31am PST sur 8/12/2026 Lever Support a lancé une requête de données backend qui a causé Lever location services de rencontrer une erreur de mémoire. Le résultat de cela a causé la dégradation du site et des charges de page échouées pour l'entreprise louage.lever.co entre 10:31am - 10:46am PST. Les utilisateurs touchés remarqueraient une erreur de 500 pendant les chargements de pages touchés. Le service a été restauré à tous les utilisateurs à partir de 10:46 am PST. À l'heure actuelle, nous travaillons sur des améliorations continues afin d'atténuer le risque que les requêtes lancées par Lever Support déclenchent des pannes à l'avenir. Une ACR complète sera affichée sur ce numéro dans les 7 à 10 jours ouvrables.

2. 14 août 2026 à 18:26 UTCpostmortem

   **Résumé de l'incident** Le 12 août 2026, entre 10h31 et 10h45, la plate-forme Lever a connu une indisponibilité partielle. Pendant cette fenêtre de 14 minutes, certains clients n'ont pas pu accéder à la plateforme, et d'autres ont connu des taux d'erreur élevés pour les demandes d'API. **Détection** La question a été cernée au moyen d'un suivi interne. Une alerte Datadog pour les défauts de page de base de données élevés déclenchés à 10:37 PDT, en informant l'équipe d'ingénierie. Cela a permis aux intervenants d'isoler les noeuds spécifiques de la base de données présentant une charge élevée et d'identifier les opérations responsables. ** Cause de la mort** L'incident a été déclenché par un mécanisme de sécurité au sein d'un outil administratif interne conçu pour prévenir les requêtes coûteuses de bases de données. Lorsqu'un opérateur a cherché des données non indexées, cette vérification de sécurité a demandé un "plan" de la base de données pour voir si la requête était sûre à exécuter. Cependant, comme les données n'étaient pas indexées, la base de données a tenté d'évaluer toutes les méthodes possibles de recherche, ce qui a permis de numériser 11 fois le même grand compte pour une seule demande. Ces vérifications diagnostiques ont contourné les délais standard, consommant la capacité de lecture de la base de données requise pour le trafic normal des clients. **Résolution** Les équipes d'ingénierie ont identifié et mis fin aux opérations de diagnostic à long terme, qui ont immédiatement rétabli la performance de la base de données et la stabilité de la plate-forme. Après le nettoyage, une protection au niveau de la base de données a été appliquée pour forcer ces requêtes spécifiques à un seul chemin efficace, empêchant la base de données d'essayer plusieurs scans coûteux à l'avenir. ** Mesures préventives** * **Reconception des contrôles de sécurité:** Nous remplaçons la méthode de diagnostic actuelle par un nouveau système qui vérifie la sécurité des requêtes en inspectant directement les définitions des bases de données, éliminant la nécessité d'effectuer des tests coûteux sur des données en direct. * **Alerte avancée**: Nous mettons en œuvre une nouvelle surveillance pour les opérations de lecture de bases de données et de longue durée pour détecter et résoudre des problèmes similaires avant qu'ils n'affectent les clients. * ** Amélioration de l'exploitation forestière :** Nous améliorons les registres de vérification interne afin d'accélérer l'identification et l'attribution des activités de base de données administratives. * Optimisation de la base de données: Nous ajoutons de nouveaux index pour soutenir correctement ces modèles de recherche, en assurant qu'ils sont intrinsèquement efficaces.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 août 2026 à 16:38 UTCinvestigating

   Question : Nous sommes au courant d'une panne active avec Adobe Sign, un fournisseur de signature électronique tiers. Cela affecte les clients de Lever qui utilisent l'intégration Adobe Sign. Impact client : Les recruteurs peuvent ne pas être en mesure de générer ou d'envoyer des lettres d'offre pour la signature électronique via Adobe Sign. Les candidats dont les demandes d'Adobe Sign sont en attente peuvent ne pas pouvoir les signer pour le moment. Les clients utilisant DocuSign et toutes les autres fonctionnalités de Lever ne sont pas touchés. Statut : Enquête. Il s'agit d'un problème en amont avec Adobe; nous surveillons et mettrons à jour car Adobe fournit plus d'informations. Pour les mises à jour directes d'Adobe, voir leur page d'état à https://status.adobe.com/

2. 7 août 2026 à 17:11 UTCinvestigating

   Mise à jour — Lettre d'offre Question : Nous avons constaté que cette perturbation était plus vaste que la portée initiale. La panne d'Adobe a un impact sur notre processus de conversion PDF, qui toutes offrent des lettres — peu importe le fournisseur de signature électronique (Adobe Sign, DocuSign ou Native eSignature) — dépendent de générer le document final. Impact client: Tous les clients sont actuellement incapables d'envoyer des lettres d'offre avec succès. Cela ne se limite plus aux utilisateurs d'intégration Adobe Sign. Les recruteurs qui tentent de générer ou d'envoyer une lettre d'offre peuvent constater des échecs ou des retards quelle que soit la méthode de signature électronique configurée sur leur compte. Statut : Enquête.

3. 7 août 2026 à 20:28 UTCidentified

   We found that our Fallback document converter in case of an Adobe PDF Services API outage is not working as expected. We are working on a fix to implement an immediate fallback document converter to prevent failed/stuck offer sends in cases of an Adobe PDF Services API outage. Next update: 4pm PST/PDT or earlier For the most up to date status on the Adobe API outage follow: https://status.adobe.com/products/503500/202608070024

4. 7 août 2026 à 21:29 UTCmonitoring

   A fix has been implement to immediately fallback to an alternate document converter after offer document conversions are stuck for a period of time. We are currently processing through a backlog of offer sends and we expect the backlog processing to take around one to two hours. Users may notice a delay sending offers, but offer documents should send successfully. Any document (resumes, offers, etc.) image previews may show loading failures while the backlog processing catches up to real time. We are continuing to actively monitor the document previewer and Adobe PDF Services API outage.

5. 7 août 2026 à 22:29 UTCresolved

   This incident has been resolved. The document converter is now processing in real time. Offers are sending with no delay and all document previews in Lever should be visible. An RCA will be available within 7-10 business days.

6. 14 août 2026 à 18:16 UTCpostmortem

   **Incident Summary** On August 7, 2026, between approximately 6:00 AM and 5:30 PM ET, some customers were unable to send offer letters, and some document and resume previews failed to generate. Files uploaded successfully; only the step that converts them into a viewable PDF or preview failed. No data was lost.  **Detection** Identified on August 7 at approximately 11:47 AM ET following customer reports to our Support team. **Root Cause** A third-party service we use to convert documents into PDFs experienced an outage lasting most of the day. During it, the service accepted conversion requests but never completed them. Our system is designed to switch to a backup conversion method when that service reports a failure — but because these requests neither succeeded nor failed, they simply waited, and the backup was never used. Each waiting request also occupied one of a limited number of conversion slots, so delays spread to other documents.  **Resolution** We added a strict overall time limit to document conversions: if the third-party service does not finish within that window, we stop waiting and convert the document using our own backup method instead. We also corrected a related defect that had prevented the backup from being used reliably. Both fixes were released to production on the afternoon of August 7, while the third-party outage was still ongoing, and conversion success rates returned to normal levels the following day. We then re-processed the documents that had failed to convert during the outage.  **Preventative Measures** ·       We fixed a defect that had prevented this service's health measurements from reaching our monitoring system and are adding alerts on the document conversion failure rate, so issues like this are detected automatically and quickly, rather than through customer reports. ·       The new time limit can be adjusted without a code release, and we are documenting a procedure to route all conversions away from the third-party service during a vendor outage.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 juillet 2026 à 14:47 UTCinvestigating

   Numéro: Nous enquêtons sur ce qui semble être une question à l'échelle de la plateforme dans laquelle les lettres d'offre ne sont pas envoyées. Impact client : À l'heure actuelle, les recruteurs ne sont pas en mesure de produire ou de fournir des courriels aux candidats. État actuel : L'ingénierie enquête activement. Aucune solution de rechange n'est actuellement disponible.

2. 14 juillet 2026 à 16:24 UTCmonitoring

   Question : Nous avons identifié un problème à l'échelle de la plateforme dans lequel les lettres d'offre n'ont pas été envoyées. Impact client : Les recruteurs n'ont pas été en mesure de générer ou de livrer des courriels aux candidats. Situation actuelle : Le problème immédiat a été atténué. Nous veillons activement à confirmer la pleine résolution et la stabilité.

3. 14 juillet 2026 à 23:50 UTCresolved

   Question : Nous avons identifié un problème à l'échelle de la plateforme dans lequel les lettres d'offre n'ont pas été envoyées. Impact client : Les recruteurs n'ont pas été en mesure de générer ou de livrer des courriels aux candidats. Statut : résolu. Un RCA sera disponible dans les 7-10 jours ouvrables.

4. 22 juillet 2026 à 13:20 UTCpostmortem

   **Résumé de l'incident** Entre le 13 et le 14 juillet 2026, certains clients ont été par intermittence incapables d'envoyer des lettres d'offre, et certains prévisualisations de documents/résumes n'ont pas pu générer. Alors que les fichiers sources ont été téléchargés avec succès, l'étape de conversion requise pour les prévisualisations et la génération d'offre a échoué. Aucune perte de données n'est survenue. **Détection** Le problème a été identifié le 14 juillet 2026, à environ 10:43 AM ET, suite aux rapports des clients à notre équipe de soutien. L'ingénierie a confirmé l'impact grâce à la surveillance, qui a montré une augmentation constante du nombre de processus au sein du service de convertisseur de documents jusqu'à ce qu'il atteigne une limite de système dure, ce qui a entraîné l'échec des tâches subséquentes. ** Cause de la mort** L'incident a été causé par une « fuite de procédé » introduite lors d'une mise à niveau récente de la plate-forme. Un changement dans la façon dont le système gère les conversions de documents signifie que chaque conversion a commencé un nouveau processus de fond qui n'a jamais été correctement fermé. Pendant plusieurs jours, ces processus de fond se sont accumulés jusqu'à ce que le système atteigne sa capacité maximale. Une fois cette limite atteinte, le service ne pouvait plus démarrer les nouveaux processus nécessaires pour générer des lettres d'offre ou des prévisualisations de documents. **Résolution** * ** Atténuation initiale :** À 11h20 ET le 14 juillet, les ingénieurs ont redémarré les modules de service touchés. Cela a effacé les processus de fond accumulés et a immédiatement restauré la capacité pour les clients d'envoyer des lettres d'offre et des aperçus de vue. * ** Correction permanente :** Une mise à jour du code a été élaborée et déployée le 14 juillet à 20 h 43 HNE. Cette solution garantit que tous les processus de fond sont correctement terminés et nettoyés après chaque conversion, empêchant ainsi toute accumulation future. ** Mesures préventives** * **Améliorations du code:** Mise en œuvre d'un solide système de gestion des processus \(en utilisant un processus « réaper »\) pour s'assurer que toutes les tâches de fond sont automatiquement terminées. * **Surveillance renforcée :** De nouvelles alertes automatisées ont été configurées pour informer l'équipe d'ingénierie si l'utilisation du processus dépasse 50 % de la limite du système. Cela nous permettra d'identifier et de résoudre des fuites de ressources semblables quelques jours avant qu'elles n'aient une incidence sur les clients. * ** Traitement des dossiers :** Une initiative distincte a été réalisée pour identifier et reproduire tout prévisualisation de document ou de curriculum vitae qui n'a pas été généré pendant la fenêtre de panne afin de s'assurer que tous les prévisualisations sont disponibles pour les utilisateurs.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 juillet 2026 à 18:04 UTCinvestigating

   Nous enquêtons sur un problème affectant l'authentification de Nylas. Les utilisateurs peuvent éprouver un message d'erreur "erreur inconnue" lorsqu'ils tentent de réinitialiser les permissions d'intégration email/calendar. Heure de début: 10h10 PT Prochaine mise à jour: 13:00 PT ou plus tôt.

2. 13 juillet 2026 à 19:57 UTCinvestigating

   Nous continuons d'enquêter sur cette question. Prochaine mise à jour: 15:00 PT ou plus tôt.

3. 13 juillet 2026 à 21:59 UTCidentified

   Nous continuons d'enquêter sur cette question. Prochaine mise à jour: 17:00 PM PT

4. 14 juillet 2026 à 00:28 UTCmonitoring

   Des mesures d'atténuation ont été appliquées et la fonctionnalité du service est de retour à la normale. Nous surveillons les performances et la stabilité. Prochaine mise à jour: après résolution.

5. 14 juillet 2026 à 13:08 UTCresolved

   Description de la question : Les utilisateurs peuvent avoir reçu une « erreur inconnue » lorsqu'ils tentent d'envoyer des courriels ou de synchroniser leur courriel et leur calendrier Microsoft dans Lever. Impact client: Les utilisateurs touchés n'ont pas pu authentifier leurs intégrations de messagerie et de calendrier Microsoft, bloquer les courriels envoyés aux candidats et la fonction de synchronisation de calendrier critique pour le recrutement des flux de travail. Statut: Résolue — Envois de courrier électronique et synchronisation de calendrier fonctionnent maintenant normalement. Un RCA sera disponible dans les 7-10 jours ouvrables.

6. 22 juillet 2026 à 13:19 UTCpostmortem

   **Résumé de l'incident** Le 13 juillet 2026, les clients utilisant Microsoft \(Office 365\) pour l'intégration de courriels et de calendrier ont connu des interruptions de service. Les utilisateurs touchés n'étaient pas en mesure d'autoriser ou de réautoriser leurs connexions de courriel et de calendrier dans Lever, rencontrant souvent un message d'« erreur inconnue ». En outre, les courriels envoyés par l'intermédiaire de l'intégration Microsoft n'ont pas livré pendant cette période. Les services de messagerie et de calendrier basés sur Google sont restés pleinement opérationnels et n'ont pas été touchés par cet incident. **Détection** Le problème a été identifié le 13 juillet 2026, à 14h22 ET, suite aux rapports des clients à notre équipe de soutien. Au moment de l'enquête, l'équipe d'ingénierie a confirmé les échecs et a lancé une réponse hautement prioritaire. Bien que l'expiration technique sous-jacente ait eu lieu le 12 juillet 2026, l'impact est devenu visible à mesure que les utilisateurs tentaient de rafraîchir leurs autorisations ou d'envoyer des communications le lendemain. ** Cause de la mort** L'incident a été causé par l'expiration d'un certificat de sécurité numérique utilisé pour communiquer en toute sécurité avec Microsoft. Ce justificatif agit comme un mot de passe sécurisé qui permet à nos systèmes de synchroniser les données de courriel et de calendrier. Comme il s'agissait d'un titre partagé utilisé pour l'intégration de Microsoft, l'expiration a affecté les clients en utilisant Office 365 largement plutôt qu'un compte spécifique. **Résolution** Pour résoudre le problème, notre équipe d'ingénierie a généré un nouveau titre de sécurité et mis à jour les paramètres d'intégration dans nos environnements. Une fois le nouveau titre propagé par le système, le service a été entièrement rétabli. La restauration a été vérifiée par des tests internes et confirmée par des réautorisations réussies de clients par 8:28 PM ET le 13 juillet 2026. Aucune perte de données n'a eu lieu à la suite de cet incident. ** Mesures préventives** Pour éviter que cette question ne se reproduise, nous mettons en œuvre les améliorations suivantes : * ** Suivi automatisé de l'expiration :** Nous établissons un processus de suivi officiel pour toutes les références d'intégration avec des rappels automatisés bien avant les dates d'expiration. * **Surveillance proactive:** De nouvelles alertes ont été configurées pour détecter les pics dans les défaillances d'autorisation, permettant à notre équipe d'identifier et de résoudre des problèmes similaires avant qu'ils n'aient une incidence sur les clients.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 8 juillet 2026 à 17:17 UTCidentified

   Le 7-3-2026, nous avons été mis au courant d'un problème touchant les instances Lever avec l'authentification Nylas (généralement utilisé pour les clients avec des services de messagerie/calendrier Microsoft Exchange sur site). Seule l'authentification Nylas est affectée, il n'y a pas eu de comportement similaire observé pour les clients authentifiant avec les services Office 365 ou Google. Les utilisateurs peuvent faire l'expérience d'un message d'erreur « 500 » lorsqu'ils tentent de réinitialiser les permissions de courriel/calendrier et nous avons observé plusieurs boucles de courriel inattendues qui font que les candidats reçoivent des courriels en double toutes les 10 à 15 minutes à la suite de ce problème. Cause principale : Les 500s et les échecs d'email sont causés par un bug connu dans Node.js v24.17.0 (https://github.com/nodejs/node/issues/63989). La version de sécurité de v24.17.0 (CVE-2026-48931) a modifié la gestion de la prise de courant "Heep-alive" de sorte que `node-fetch` lance `ERR STREAM PREMATURE CLOSE` ("Premature close") sur les réponses gzipped à des fournisseurs externes (Nylas/Google). Nos services ont récupéré ce bug via la migration Node 18→24 (décurré le 06-30-2026). Le bug a été corrigé en amont dans Node 24.18.0 Cette question devrait être réglée lors d'un déploiement aujourd'hui (7-8-2026). Nous fournirons dès que possible des mises à jour sur l'état de la question et le calendrier de déploiement.

2. 8 juillet 2026 à 20:03 UTCmonitoring

   Une correction a été mise en œuvre à partir d'environ 12h15 PST/PDT le 7/8/2026. La synchronisation de l'email et du calendrier est désormais entièrement fonctionnelle pour les instances Lever configurées avec l'authentification Nylas. Nous continuons de surveiller l'efficacité de la correction. Une analyse des causes profondes sera publiée à ce sujet dans le cadre de l'entente type sur les niveaux de service.

3. 9 juillet 2026 à 16:19 UTCresolved

   Cet incident est résolu. Une analyse des causes profondes sera publiée dans ce numéro dans les 7-10 jours ouvrables.

4. 9 juillet 2026 à 20:43 UTCpostmortem

   **Résumé de l'incident** Entre le 2 juillet 2026 et le 8 juillet 2026, certains clients ont connu des défaillances intermittentes affectant les services de messagerie et de calendrier. Les principaux impacts comprenaient des erreurs lors de l'envoi ou de la synchronisation des courriels et occasionnellement des « 500 erreurs » pendant la connexion. Ces problèmes ont été causés par une régression technique dans l'environnement d'exécution sous-jacent \(Node.js\) qui gère les connexions sortantes aux services tiers. Pour un sous-ensemble de clients utilisant des paramètres spécifiques d'intégration d'email, l'instabilité de connexion a causé au système de percevoir incorrectement un e-mail envoyé avec succès comme un échec. Cela a déclenché un mécanisme de ré-essai automatisé, qui a parfois donné lieu à une « boucle de ré-essai » où la même communication a été renvoyée aux destinataires à intervalles réguliers jusqu'à ce que la connexion soit stabilisée. **Détection** La question a été soulevée à la suite de rapports de perturbations intermittentes du service. Nos équipes de soutien et d'ingénierie ont mené une enquête approfondie sur ces rapports, en identifiant un schéma spécifique de défaillances de connexion dans nos registres de systèmes. Une analyse plus approfondie a confirmé que l'impact a commencé vers le 2 juillet 2026, après une mise à jour régulière de notre infrastructure de services. ** Cause de la mort** La cause principale était un défaut dans une version spécifique de Node.js \(version 24.17. Cette version contenait une faille dans la façon dont elle gérait les connexions « de garde-vive », des connexions réutilisables utilisées pour communiquer avec des services externes. Dans certaines conditions, le logiciel fermerait prématurément ces connexions avant qu'une tâche ne soit terminée, ce qui se traduirait par des courriels et des erreurs de synchronisation des données. **Résolution** Pour résoudre le problème, notre équipe d'ingénieurs a effectué les étapes suivantes : * **Identification :** Correspond aux erreurs « Premature close » à une régression connue dans le Node.js runtime. * ** Mise à niveau :** Mise à jour de nos images système de base en Node.js version 24.18.0, qui contient la correction officielle pour ce problème de connexion. * **Déploiement:** Reconstruire et redéployer les services essentiels \(y compris les composants de courriel et de calendrier\) sur la version corrigée. * **Vérification :** Confirmé que les erreurs de connexion ont cessé et que la stabilité du service est revenue à des niveaux normaux le 8 juillet 2026. ** Mesures préventives** Pour éviter des problèmes similaires à l'avenir, nous mettons en oeuvre les améliorations suivantes : * ** Pinning de version:** Nous avons mis à jour notre processus de construction pour nous assurer que nous déployons uniquement des versions qui ont été entièrement vérifiées. * **Surveillance renforcée :** Nous ajoutons des alertes spécifiques pour les erreurs de connexion sortantes pour détecter et répondre plus rapidement à des défaillances de communication similaires. * ** Essais automatisés :** Nous mettons en place de nouvelles vérifications synthétiques pour la synchronisation des courriels et des calendriers afin d'identifier les problèmes de façon proactive avant qu'ils n'aient une incidence sur les clients. * **Visibilité améliorée :** Nous mettons à jour nos tableaux de bord internes afin d'offrir une meilleure visibilité dans les versions logicielles exactes de notre environnement de production pour accélérer les diagnostics futurs.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 juin 2026 à 14:44 UTCinvestigating

   We are currently investigating an issue impacting access to our platforms. A broader Cloudflare service disruption is affecting connectivity, resulting in: Request timeouts Increased latency and slow page loads Cloudflare-generated error pages (including 5xx errors) Intermittent access to platform services Our teams are actively monitoring the situation and assessing the impact on our services. While the issue appears to originate from Cloudflare's infrastructure, we continue to monitor service health and will provide updates as additional information becomes available. Customers can monitor Cloudflare's incident status directly at: https://www.cloudflarestatus.com/ Start Time: ~9:35 EDT We apologize for the inconvenience and appreciate your patience while service providers work to restore normal operations. Customer Impact: Users may experience intermittent access issues, delayed responses, request failures, or Cloudflare error pages when accessing platform services. Reference: Cloudflare Status Page — https://www.cloudflarestatus.com/

2. 22 juin 2026 à 16:17 UTCidentified

   Monitoring Third-Party Network Issue Status: We continue to monitor an ongoing third-party network incident affecting Cloudflare, which is causing intermittent timeouts, increased latency, and occasional Cloudflare error pages for some users accessing our platforms. Based on updates from Cloudflare, the issue is related to a network infrastructure event in North America, and their engineering teams are actively rerouting traffic and implementing mitigation measures to restore service stability. At this time, the underlying issue resides with a third-party provider and is outside of our direct control. Our teams are closely monitoring the situation and validating service availability as Cloudflare implements corrective actions. Customers may continue to experience intermittent connectivity issues, slow response times, or timeout errors until Cloudflare has fully resolved the incident. For the latest updates, please monitor Cloudflare's status page directly: https://www.cloudflarestatus.com/ We appreciate your patience and will continue to provide updates as new information becomes available.

3. 22 juin 2026 à 18:21 UTCresolved

   Cloudflare has reported that its traffic engineering efforts have successfully mitigated the majority of congestion and packet loss associated with this incident. As a result, service conditions are improving; however, some users may still experience intermittent connectivity issues while their recovery efforts continue. Customer Impact: Most services have stabilized, but some users may continue to experience intermittent latency, timeouts, or connectivity issues during the final stages of recovery. Customers can monitor the latest updates directly on Cloudflare's status page: https://www.cloudflarestatus.com/ We will continue to provide updates as new information becomes available.

1. 16 juin 2026 à 22:25 UTCinvestigating

   We became aware of an issue affecting the North America data center where Visual Insights is not loading new data in some customer accounts. The issue started occurring on Tuesday, 6/16/2026 at approximately 7:30am PST/PDT. Updates will be provided as we work to investigate the issue.

2. 16 juin 2026 à 22:33 UTCinvestigating

   We are continuing to investigate this issue affecting Visual Insights. New data may be delayed to appear in Visual Insights or may be missing. Start time: 6/16/2026 7:30am PST/PDT Next update: 6/17/2026 8am PST/PDT or sooner.

3. 17 juin 2026 à 18:31 UTCidentified

   We have identified the issue affecting the Visual Insights (Snowflake) database and have implemented a fix on Wednesday, June 17 at approximately 10:30am PST/PDT.

4. 17 juin 2026 à 18:33 UTCmonitoring

   We are continuing to monitor the effectiveness of the fix for Visual Insights reporting. We anticipate that reporting data may still have discrepancies for approximately 10 to 15 hours. We are continuing to monitor that data is backfilling on schedule as expected. Next update: 6/17/2026 5pm PST/PDT or sooner.

5. 18 juin 2026 à 16:24 UTCresolved

   The data backfill has completed at approximately 5:00am PST/PDT on 6/18/2026. All Visual Insights reports should now be a complete and accurate representation of current data. A root cause analysis (RCA) will be published to this incident within the standard Service Level Agreement (SLA).

6. 22 juin 2026 à 19:49 UTCpostmortem

   #### **Incident Summary** Between June 14 and June 18, 2026, analytics reports in the Visual Insights "Custom Data Explorer" displayed outdated information. While the live platform remained fully accurate and no data was lost, the reports stopped reflecting real-time changes \(such as candidate stage updates\). This resulted in a "stale" snapshot of data being shown to all reporting customers for approximately four days. **Detection** The issue was identified on June 17, 2026, following reports from customers who noticed that their report counts did not match the live data in the platform. Upon investigation, our engineering team confirmed that the data pipeline responsible for updating these reports had stopped processing new information on June 14. #### **Resolution** Once identified, our engineering team restarted the affected component, which safely resumed and caught up on all pending changes with no data loss. Report accuracy was fully restored, and the cited figures now match the live platform. No action was required from customers at any point. #### **Preventative Measures** To prevent this issue from recurring, we have taken the following actions: * **Enhanced Auto-Recovery:** We updated the system to automatically recognize and recover from this specific type of database restart error, allowing it to self-heal without manual intervention. * **Improved Monitoring:** We are implementing more granular alerts that monitor the specific workers within the data pipeline. This ensures that if a single worker stops, we are notified within minutes. * **Data Freshness Checks:** We are adding new automated checks that compare live platform data against the reporting store to detect any "freshness" gaps immediately.

1. 11 juin 2026 à 17:28 UTCinvestigating

   We are investigating an issue affecting the LinkedIn Job Board integration. Users may experience inaccurate posting locations appearing in LinkedIn when passing postings via the LinkedIn Job Board integration, we do not currently have any reports of inaccuracies from the LinkedIn Apply Connect integration. Start time: 9:00 AM Pacific 6/11/2026 Next update: 12:30 PM 6/11/2026 or sooner.

2. 11 juin 2026 à 19:33 UTCinvestigating

   We are continuing to investigate this issue in partnership with the LinkedIn team. Next Update 2:30 PM Pacific 6/11/2026 or sooner

3. 11 juin 2026 à 21:42 UTCinvestigating

   We are continuing to investigate this issue in partnership with the LinkedIn team. Next Update 4:30 PM Pacific 6/11/2026 or sooner

4. 11 juin 2026 à 23:25 UTCinvestigating

   We are continuing to investigate this issue in partnership with the LinkedIn team. Next Update 9:30 AM Pacific 6/12/2026 or sooner

5. 12 juin 2026 à 16:43 UTCinvestigating

   We are continuing to investigate this issue in partnership with the LinkedIn team. Next Update 11:30 AM Pacific 6/12/2026 or sooner

6. 12 juin 2026 à 19:03 UTCinvestigating

   We are continuing to investigate this issue in partnership with the LinkedIn team. Next Update 1:30 PM Pacific 6/12/2026 or sooner

7. 12 juin 2026 à 19:10 UTCresolved

   Posting Locations should now be populating as expected. Please follow up with Lever Support if you see any postings continuing to display an inaccurate location in LinkedIn.

1. 23 avril 2026 à 18:26 UTCinvestigating

   We are investigating an issue affecting some users Microsoft Office 365 email/calendar services are unable to schedule interview events or send emails in Lever. The impact appears to be limited to only accounts where Administrator Consent for email/calendar permissions is enabled. Affected users are currently unable to schedule interviews or send emails in Lever and may see one or more error messages including “Could not load events” and/or “Your email/calendar integration isn't working” related to scheduling and email. We are currently investigating this issue and will provide updates from our Engineering team as new information becomes available. Users may experience issues when scheduling interviews or sending emails. Start time: April 21, 2026, 1:40 PM PDT

2. 23 avril 2026 à 20:11 UTCresolved

   This incident has been resolved. Incident Duration: April 21, 2026, 1:40 PM– April 23, 2026 11:00 AM PT Impact Summary: During this window, customers using Microsoft Office365 were unable to retrieve interviewer availability or schedule interviews. Existing data was not lost, but new scheduling actions failed until service was restored. Cause: An internal encryption key rotation was completed for several services, but a related dependency used by the calendar service was not updated. As a result, the calendar service was unable to read newly issued Microsoft access tokens, causing scheduling requests to fail for Office365-connected accounts. Mitigation: The calendar service was updated to use the correct dependency compatible with the new encryption keys. Once deployed, scheduling functionality was fully restored and verified in production. An RCA will be provided within 7-10 business days if applicable.

1. 21 avril 2026 à 21:07 UTCinvestigating

   Around 8:50am PT on 4/21/2026 we became aware of an issue where some users Microsoft Office 365 email/calendar services are unable to schedule interview events or send emails in Lever. The impact appears to be limited to only accounts where Administrator Consent for email/calendar permissions is enabled. Affected users are currently unable to schedule interviews or send emails in Lever and may see one or more error messages including “Could not load events” and/or “Your email/calendar integration isn't working” related to scheduling and email. We are currently investigating this issue and will provide updates from our Engineering team as new information becomes available.

2. 21 avril 2026 à 23:26 UTCinvestigating

   We are continuing to investigate this issue.

3. 22 avril 2026 à 01:05 UTCmonitoring

   We have identified the issue causing failed Lever user permission syncs with Microsoft Office 365 email/calendar services for users with Administrator provided email/calendar permissions. A fix was deployed at approx. 4:39pm PT on 4/21/2026. We are actively monitoring the fix to ensure continued email/calendar sync availability.

4. 22 avril 2026 à 12:07 UTCresolved

   This incident has been resolved. Issue: Users with Microsoft 365 calendar integrations experienced authentication failures, causing email and calendar sync to stop working. Resetting the calendar cache resulted in an endless loading state. Impact: Affected users were unable to schedule interviews or view availability in Lever. The issue was limited to accounts using Admin Consent–based Microsoft 365 authentication. A fix was applied at approximately 4:39 pm PDT on 4/24/2026. An RCA will be available within 7-10 business days if applicable.

5. 23 avril 2026 à 13:33 UTCpostmortem

   We want to share an update on a recent automation issue, including what happened, how it was resolved, and the steps we’ve taken to prevent it from happening again. **Date/Time:** April 21, 2026, **1:40 PM – 4:39 PM PDT** **Duration:** **2 hours 59 minutes** ### Customer Impact During this window, customers using Microsoft Office365 were unable to retrieve interviewer availability or schedule interviews. Existing data was not lost, but new scheduling actions failed until service was restored. ### Root Cause An internal encryption key rotation was completed for several services, but a related dependency used by the calendar service was not updated. As a result, the calendar service was unable to read newly issued Microsoft access tokens, causing scheduling requests to fail for Office365-connected accounts. ### Resolution The calendar service was updated to use the correct dependency compatible with the new encryption keys. Once deployed, scheduling functionality was fully restored and verified in production. ### Preventative Actions * Expand automated test coverage to explicitly validate scheduling flows for Microsoft Office365 accounts. * Improve internal validation and service dependency checks during encryption key rotations.

1. 17 avril 2026 à 17:45 UTCinvestigating

   We are currently investigating an issue preventing new API keys from being generated in our EU environment (EUDC). Impact: Existing or pre-existing API connections in the EU region may also be impacted. Global (non-EU) environments remain unaffected at this time. Updates to follow shortly

2. 17 avril 2026 à 18:53 UTCresolved

   This incident has been resolved. Impact Summary: Customers may have had an issue preventing new API keys from being generated in our EU environment (EUDC). Existing or pre-existing API connections in the EU region may also be impacted. Global (non-EU) environments were unaffected An RCA will be provided within 7-10 business days if applicable.

1. 17 avril 2026 à 17:15 UTCinvestigating

   We are currently investigating this issue.

2. 17 avril 2026 à 17:33 UTCidentified

   Impact: Partial outage – subset of users unable to access Lever We are investigating reports that some users receive a “Site Not Found” error when accessing hire.lever.co and related pages. This issue appears limited to a subset of customers and is related to an ongoing incident with our upstream network provider (Cloudflare): https://www.cloudflarestatus.com/ Our systems are operating normally, but connectivity for some users is being impacted by this third‑party provider. We are monitoring their incident and will provide updates as more information becomes available. There is currently no known workaround.

3. 17 avril 2026 à 17:36 UTCidentified

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

4. 17 avril 2026 à 18:59 UTCmonitoring

   Cloudflare has implemented a fix for this issue and are currently monitoring. Impact: Partial outage – a subset of users were unable to access Lever Some users may have received a “Site Not Found” error when accessing hire.lever.co and related pages. For updated info and an RCA, refer to Cloudflare's status page: https://www.cloudflarestatus.com/

5. 17 avril 2026 à 21:11 UTCresolved

   This incident has been resolved.

1. 27 mars 2026 à 18:07 UTCresolved

   At about 3:00pm PST on 3/26/2026 the Lever Support Team triggered a data operation job through an internal admin interface. The data required for this job did not have sufficient database indexes available on the server which caused significant strain on the database servers. The result of this caused site degradation and failed page loads for hire.lever.co between 3:04pm - 3:26pm PST. Impacted users would notice a "500 error" during the affected page loads. Service was restored to all users as of 3:26pm PST. Following this time we continued to optimize the databases for the intended data operation. Full functionality was reached at about 10:00pm PST.

1. 26 mars 2026 à 12:02 UTCinvestigating

   We are investigating an issue affecting the availability of reporting data. Users may experience delays in getting up-to-date reporting data, specifically related to profile cards. Start time: Approximately 4 am EST Next update: 10 am EST or sooner.

2. 26 mars 2026 à 12:36 UTCidentified

   We have identified the root cause affecting the delay of data related top profile cards. Mitigation is currently in progress. Next update: 10:30 am EST or sooner.

3. 26 mars 2026 à 14:12 UTCmonitoring

   Mitigation steps have been applied and service functionality is returning to normal and processing of delayed data should be complete within the next 2 hours. We are monitoring for continued performance and stability. Next update: 12 pm EST or upon full resolution.

4. 26 mars 2026 à 14:13 UTCmonitoring

   We are continuing to monitor for any further issues.

5. 26 mars 2026 à 18:13 UTCresolved

   This incident has been resolved. Impact Summary: Users may have experienced delays in getting up-to-date reporting data, specifically related to profile cards. Incident Duration: Started at approximately 4 am EST and resolution confirmed at 9 am EST An RCA will be provided within 7-10 business days

1. 5 mars 2026 à 19:59 UTCidentified

   We’ve identified the issue causing the "enable AI Interview Companion for all postings" button to not work, and we’re working to implement a fix. Additional updates will be provided as soon as a resolution is in place.

2. 6 mars 2026 à 21:25 UTCidentified

   We’ve completed a fix for the issue that caused the “Enable AI Interview Companion for all postings” button to stop working. The team is currently finishing testing, and the release is planned for Monday, March 9. Additional updates will be provided as soon as the fix is deployed. Next update: Monday, March 9 at 12:00 PM ET or earlier.

3. 9 mars 2026 à 16:36 UTCidentified

   We’ve completed a fix for the issue that caused the “Enable AI Interview Companion for all postings” button to stop working. The release is expected to be deployed today. Next update: Monday, March 9, at 5:00 PM ET or earlier.

4. 9 mars 2026 à 18:13 UTCresolved

   The issue with the AI Interview Companion Enable for all Jobs settings in Lever has been resolved. The incident occurred from 11:59 am PST 3/6/2026 - 10 am PST 3/9/2026. There should be no further impact at this time, but please reach out to us at Support if any additional assistance is needed: https://help.lever.co/hc/en-us/requests/new

1. 11 février 2026 à 18:26 UTCinvestigating

   We are currently investigating an issue that is causing general opportunities to be created when an opportunity is archived. Issues impacting candidate archiving were noticed around February 10, 2026 at 1:00 PM PT. Our Engineering teams are actively working to resolve this as soon as possible.

2. 11 février 2026 à 20:08 UTCidentified

   We’ve identified the issue causing general opportunities to be created when an opportunity is archived, and we’re working to implement a fix. Additional updates will be provided as soon as a resolution is in place.

3. 12 février 2026 à 01:36 UTCresolved

   The issue where general opportunities were showing when archiving opportunities has been resolved. The incident occurred from February 10, 2026 at 1:00 PM PT to February 11, 2026 at 5:30 PM PT. There should be no further impact at this time, but please reach out to us at Support if any additional assistance is needed: https://help.lever.co/hc/en-us/requests/new

1. 4 février 2026 à 12:04 UTCinvestigating

   We are currently investigating an issue that is intermittently affecting the API. Our Engineering teams are actively working to resolve this as soon as possible.

2. 4 février 2026 à 12:33 UTCidentified

   The issue has been identified and we are working on the fix.

3. 4 février 2026 à 12:37 UTCmonitoring

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

4. 4 février 2026 à 13:05 UTCresolved

   The incident occurred from 3:30 am Pacific time until 5:00 am Pacific time. No further action will be required from impacted users to have restored functionality. There should be no further impact at this time, but please reach out to us at Support if any additional assistance is needed: https://help.lever.co/hc/en-us/requests/new

1. 29 janvier 2026 à 19:04 UTCinvestigating

   We are currently investigating this issue.

2. 30 janvier 2026 à 20:38 UTCmonitoring

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

3. 31 janvier 2026 à 00:34 UTCresolved

   This incident has been resolved.