API and Platform not reachable
Incident Report for SMSFactor
Postmortem

🇫🇷 Version française plus bas

Overview

Our IP failover 62.210.31.127 used on the configuration of our hosting provider to redirect towards frontend server stopped working, resulting in a timeout. In other words, all services hosted on our frontend server were unreachable (Platforms, API, short links, Hubspot integration, documentation). All API requests made during the incident were lost. To solve this, we had to edit the smsfactor.com DNS zone A entry to point directly towards frontend server IP, meaning each user had to wait for the DNS propagation to be reflected.

Timeline (CET)

How did the issue unfold

  • 10h00 - The IT team responded after seeing Slack monitoring channel alerts
  • 10h01 - First investigation
  • 10h07 - Incident created on status page
  • 10h30 - First diagnostic about the IP failover at our hosting provider level
  • 10h40 - Ticket created at our hosting provider
  • 11h12 - Call to hosting provider so that we can escalate the ticket
  • 11h30 - Decision to edit the DNS settings as an emergency solution for Platforms, API, Hubspot integration
  • 12h00 - DNS change for our short-links domains as well
  • 12h20 - DNS change for Reminder domains
  • 13h00 - The situation seems to be stabilized

User facing impact

  • Platform unavailable (timeout)
  • API unavailable (timeout)
  • Beta platform (data not loading)
  • Reminders (Impossible de manage subscriptions and calendars)

    • NB : SMS from already configured calendars worked as expected
  • Hubspot integration unavailable (timeout)

  • Short links unavailable (timeout)

  • Mail2SMS unavailable (timeout)

  • How many customers were impacted?

    • Absolutely all of them except for reminder users who already had their calendars set up
  • Did we lose any data (e.g simulations)?

    • Since the API was unreachable during the event, no data could be created or modified whatsoever. Meaning all data sent to the API during the event is unavailable from our side.

Duration

  • Start: 10h00
  • Stop: Between 11h30 and several hours after depending on each user’s capability to flush DNS or acknowledge DNS propagation
  • Downtime: Yes
  • Downtime duration *: At least an hour and a half
  • Customer impact: Yes
  • Customer impact duration **: At least an hour and a half

Resolution

By changing the zone DNS A entry so that it points directly towards the frontend server and bypassing the IP failover.

NB: While this solution indeed solves the issue, this remains a temporary solution.

Follow-up action items

What actions should we take?

  • We’re actively gonna look for solutions/alternatives when it comes to IP Failover and DNS (ex: multiple DNS A entries to provide multiple IPs in case one fails)
  • We’re gonna consider IP failover and DNS zone as a serious SPOF
  • We will rethink our infrastructure to make it more robust, redundant and resilient. We underestimated the probability of having an IP failover not working properly

‌

🇫🇷

Aperçu

Notre IP failover 62.210.31.127 utilisée dans la configuration de notre hébergeur pour rediriger vers le serveur frontal a cessé de fonctionner, entraînant un timeout. En d'autres termes, tous les services hébergés sur notre serveur frontal étaient inaccessibles (Plateformes, API, liens courts, intégration Hubspot, documentation). Toutes les requêtes API effectuées pendant l'incident ont été perdues. Pour résoudre ce problème, nous avons dû modifier la zone DNS smsfactor.com pour pointer directement vers l'adresse IP du serveur frontal, ce qui signifie que chaque utilisateur était contraint d’attendre la propagation DNS.

Chronologie (CET)

Comment le problème s'est-il déroulé.

  • 10h00 - L'équipe informatique a répondu après avoir vu les alertes du canal de surveillance de Slack
  • 10h01 - Première enquête
  • 10h07 - Incident créé sur la page de statut
  • 10h30 - Premier diagnostic concernant l’IP failover au niveau de notre fournisseur d'hébergement
  • 10h40 - Ticket créé auprès de notre fournisseur d'hébergement
  • 11h12 - Appel au fournisseur d'hébergement afin que nous puissions escalader le ticket
  • 11h30 - Décision de modifier les paramètres DNS comme solution d'urgence pour les plateformes, l'API et l'intégration Hubspot
  • 12h00 - Modification DNS pour nos domaines de liens courts
  • 12h20 - Modification DNS pour les domaines de Rappel de rendez-vous
  • 13h00 - La situation semble être stabilisée

Impact pour l'utilisateur

  • Plateforme indisponible (timeout)
  • API indisponible (timeout)
  • Plateforme bêta (données non chargées)
  • Rappels de rendez-vous (impossibilité de gérer les abonnements et les calendriers)

    • NB : Les SMS provenant des calendriers déjà configurés ont fonctionné comme prévu
  • Intégration Hubspot indisponible (timeout)

  • Liens courts indisponibles (timeout)

  • Mail2SMS indisponible (timeout)

  • Combien de clients ont été impactés ?

    • Absolument tous, à l'exception des utilisateurs de rappels qui avaient déjà configuré leurs calendriers
  • Avons-nous perdu des données ?

    • Étant donné que l'API était inaccessible pendant l'événement, aucune donnée n'a pu être créée ou modifiée. Cela signifie que toutes les données envoyées à l'API pendant l'événement sont indisponibles de notre côté.

Durée

  • Début : 10h00
  • Fin : Entre 11h30 et plusieurs heures après en fonction de la capacité de chaque utilisateur à vider le cache DNS ou à reconnaître la propagation DNS
  • Temps d'arrêt : Oui
  • Durée de l'arrêt * : Au moins 1h30
  • Impact sur le client : Oui
  • Durée de l'impact sur le client ** : Au moins 1h30

Résolution

En modifiant l'entrée A de la zone DNS pour qu'elle pointe directement vers le serveur frontal et contourne l’IP failover.

NB : Bien que cette solution résolve effectivement le problème, il s'agit néanmoins d'une solution temporaire.

Actions de suivi

  • Nous allons nous renseigner activement sur les solutions en matière d'IP failover et de DNS (par exemple, plusieurs entrées DNS type A pour fournir plusieurs adresses IP en cas de défaillance de l’une d’entre elles)
  • Nous allons sérieusement considérer l’IP failover et la zone DNS comme un SPOF
  • Nous allons repenser notre infrastructure afin de la rendre plus robuste, résiliente et redondante
Posted Oct 11, 2023 - 16:00 CEST

Resolved
This incident has been resolved.
Posted Oct 10, 2023 - 16:15 CEST
Update
We are continuing to monitor for any further issues.
Posted Oct 10, 2023 - 16:15 CEST
Monitoring
The situation has been stabilized for an hour now, with the new IP being correctly resolved by most DNS servers. If you still can't reach our services, feel free to send an email to support@smsfactor.com
Posted Oct 10, 2023 - 13:17 CEST
Update
For those who have control over their DNS resolution, we switched our Failover IP in the DNS zone so that api.smsfactor.com points directly towards our front server which IP is 51.159.21.54. We'll revert the change as soon as the Failover IP is working again. In the mean time, feel free to directly use this IP to reach our services.
Posted Oct 10, 2023 - 11:29 CEST
Update
We're still working with our host provider to implement a fix to the network issue. We apologize for the trouble, your patience is deeply appreciated.
Posted Oct 10, 2023 - 11:22 CEST
Identified
We found out that the issue is because of our failover IP that doesn't redirect towards services properly. We're reaching out to our provider and hope to fix this issue as fast as possible.
Posted Oct 10, 2023 - 10:41 CEST
Investigating
We are currently investigating this issue.
Posted Oct 10, 2023 - 10:07 CEST
This incident affected: API and Customers Portal.