Le 10 septembre 2026, de 6 h 41 à 6 h 45 (heure de l'Est), notre serveur de base de données a atteint sa limite de connexions et le tableau de bord a renvoyé des erreurs. Une limite de connexions ajoutée dans la matinée a ensuite refusé des connexions pendant cinq minutes, de 11 h 14 à 11 h 19 : certains appels entrants ont reçu une tonalité d'occupé et certains SMS n'ont pas pu être envoyés. L'incident est terminé et la cause est corrigée depuis 11 h 55.

Nous savons que vos appels et vos messages passent par nous : quand Callizy s'arrête, c'est votre entreprise qui ne répond plus. Toute interruption est inacceptable. Nous sommes désolés.

Impact

Toutes les heures sont en heure de l'Est (Montréal).

Service	Impact
Tableau de bord web	Erreurs de 6 h 41 à 6 h 45, puis ponctuellement de 11 h 14 à 11 h 19.
Appels entrants	Tonalité d'occupé sur certains appels de 11 h 14 à 11 h 19. Les appelants qui ont rappelé ont été mis en relation.
SMS depuis l'application mobile	Envois refusés et boîte de réception indisponible de 11 h 17 à 11 h 19.
Appels sortants et appels en cours	Non touchés.
Page de statut	Sonde « Notifications push » en panne de 6 h 41 à 6 h 45.

Des clients ont été touchés pendant 4 minutes le matin et 5 minutes en fin de matinée. Aucune donnée n'a été perdue et aucun appel en cours n'a été coupé.

Chronologie

Heure de l'Est	Statut	Description
6 h 41	Impact	Le serveur de base de données atteint sa limite de connexions. Le tableau de bord renvoie des erreurs.
6 h 45	Rétabli	Les connexions inutilisées sont libérées. Le service répond de nouveau.
11 h 05	Correctif	Une limite de connexions est posée pour contenir toute fuite future.
11 h 14	Impact	Cette limite refuse des connexions légitimes. Appels entrants et SMS touchés.
11 h 19	Rétabli	Limite ajustée. Plus aucune erreur.
11 h 55	Correctif	La cause de fond est corrigée et déployée.
12 h 20	Surveillance	Alerte posée sur le nombre de connexions en service.

Ce qui s'est passé

Callizy tourne sur un serveur d'application asynchrone. Dans ce mode, chaque requête est traitée dans un fil d'exécution qui disparaît une fois la réponse envoyée. Notre configuration demandait pourtant à l'application de garder chaque connexion à la base de données ouverte dix minutes pour la réutiliser. Personne ne la réutilisait : le fil qui l'avait ouverte n'existait plus. Chaque requête laissait donc derrière elle une connexion ouverte pour dix minutes.

En temps normal, ce gaspillage restait sous la limite. Le 10 septembre au matin, deux choses se sont ajoutées. La version précédente de l'application, conservée en réserve après une mise à jour pour permettre un retour arrière, gardait elle aussi ses connexions ouvertes. Et un pic de requêtes a doublé le rythme. À 6 h 41, la limite a été atteinte et le serveur de base de données a refusé toute nouvelle connexion.

Dans la matinée, en attendant le correctif de fond, nous avons posé une limite de connexions à l'application, pour contenir toute fuite future. Réglée trop bas, elle a brièvement refusé des connexions légitimes à 11 h 14. Nous l'avons ajustée en cinq minutes. Le correctif de fond a été déployé à 11 h 55.

Ce que nous changeons

• Les connexions sont fermées à la fin de chaque requête. C'est la configuration que recommande le cadre logiciel que nous utilisons pour ce mode de serveur. Résultat mesuré : au repos, plus aucune connexion ne reste ouverte entre deux requêtes.
• Une alerte prévient l'équipe bien avant la limite.
• Chaque mise à jour libère automatiquement les ressources de la version précédente, 30 minutes après la bascule.
• Les limites de connexions sont calibrées sur la charge réelle, mesurée sur plusieurs jours.

Nous nous excusons de nouveau auprès de nos clients et de leurs appelants.

---

English

On September 10, 2026, from 6:41 to 6:45 a.m. (Eastern Time), our database server reached its connection limit and the dashboard returned errors. A connection limit added later that morning then refused connections for five minutes, from 11:14 to 11:19 a.m.: some inbound calls received a busy tone and some SMS could not be sent. The incident is over and the root cause has been fixed since 11:55 a.m.

We know your calls and messages go through us: when Callizy stops, your business stops answering. Any interruption is unacceptable. We are sorry.

Impact

All times are Eastern Time (Montreal).

Service	Impact
Web dashboard	Errors from 6:41 to 6:45 a.m., then intermittently from 11:14 to 11:19 a.m.
Inbound calls	Busy tone on some calls from 11:14 to 11:19 a.m. Callers who called back were connected.
SMS from the mobile app	Sending refused and inbox unavailable from 11:17 to 11:19 a.m.
Outbound calls and calls in progress	Not affected.
Status page	"Push notifications" check reported down from 6:41 to 6:45 a.m.

Customers were affected for 4 minutes in the morning and 5 minutes late morning. No data was lost and no call in progress was dropped.

Timeline

Eastern Time	Status	Description
6:41 a.m.	Impact	The database server reaches its connection limit. The dashboard returns errors.
6:45 a.m.	Recovered	Unused connections are released. The service responds again.
11:05 a.m.	Fix	A connection limit is set to contain any future leak.
11:14 a.m.	Impact	This limit refuses legitimate connections. Inbound calls and SMS affected.
11:19 a.m.	Recovered	Limit adjusted. No more errors.
11:55 a.m.	Fix	The root cause is fixed and deployed.
12:20 p.m.	Monitoring	Alert set on the number of connections in use.

What happened

Callizy runs on an asynchronous application server. In this mode, each request is handled by an execution thread that disappears once the response is sent. Our configuration nevertheless asked the application to keep each database connection open for ten minutes so it could be reused. Nobody reused it: the thread that had opened it no longer existed. Each request therefore left behind a connection that stayed open for ten minutes.

Under normal conditions, this waste stayed below the limit. On the morning of September 10, two things added up. The previous version of the application, kept in reserve after an update to allow an instant rollback, was also holding its connections open. And a spike in requests doubled the pace. At 6:41 a.m., the limit was reached and the database server refused any new connection.

Later that morning, while the root cause fix was being prepared, we set a connection limit on the application to contain any future leak. Set too low, it briefly refused legitimate connections at 11:14 a.m. We adjusted it within five minutes. The root cause fix was deployed at 11:55 a.m.

What we are changing

• Connections are closed at the end of every request. This is the configuration recommended by the framework we use for this server mode. Measured result: at rest, no connection stays open between two requests.
• An alert warns the team well before the limit.
• Every update automatically releases the resources of the previous version, 30 minutes after the switch.
• Connection limits are calibrated on real load, measured over several days.

We apologize again to our customers and to their callers.

Appels recovered.

Appels went down.

App mobile recovered.

App mobile went down.