Cronofy Says Nothing Alerted It When Scheduled Notifications in Its US Data Center Failed to Send for Almost Six Days

On its own status page, Cronofy published an incident report, with a postmortem posted on July 8, 2026, about notifications that were supposed to fire at set times and did not. Parts of it follow, not the whole.

Notifications That Quietly Backed Up

Between approximately 02:25 UTC on July 1 and 10:11 UTC on July 7, 2026, the postmortem says, scheduled notifications in the company's US data center failed to send. They were queued but never picked up, and were flushed once the underlying cause was cleared. The impact was limited to customers in that data center using notification-driven API features. Approximately 9,000 Event Trigger notifications, for calendar events starting and ending, were delivered late; a small number of Scheduler Workflows lifecycle notifications were also delivered late; and a small number of scheduled Meeting Agents did not arrive to their meetings.

The cause, the company says, was a regression introduced on April 22 in an internal service responsible for sending scheduled notifications. The service uses leader election, so that a single process hands out the imminent notifications at any one time, coordinated through a lock. The regression made that configuration fragile: if a leader did not release the lock cleanly, no other process would override it. When the leader stopped in the early hours of July 1, it left the lock held, and with no process able to take over, the postmortem says, notifications "quietly backed up from that point."

Its timeline says the change merged on April 22 made the lock-holding fragile, and that "The fault is latent and has no immediate effect."

Nothing Alerted

"Nothing alerted us to this. The failure mode was an absence of activity rather than an error, and we had no alerting on notification throughput that would have caught the drop-off."

A support ticket on July 2 reported an issue with Event Triggers. A second ticket on July 6 reported another. On July 7 the pattern across the two tickets was identified internally and raised; telemetry then showed a clear drop-off in notification sends; the held lock was raised as the probable cause and cleared by hand at 10:07, and the backlog was flushed within four minutes.

The system did not fail loudly. It stopped doing its job and said nothing, and the first signal came from support tickets.

The Company's Own Questions

The postmortem asks three questions of itself. Could the issue have been resolved sooner? Once the right thing was being looked at, it says, resolution was fast. Could it have been identified sooner? "This is where we fell short, and badly." The failure, it says, was live for almost six days. It had no alerting on notification throughput, "so a complete stop in sending produced no signal," and the first support ticket did not surface the pattern. It took a second ticket, four days later, for the connection to be made.

Could it have been prevented? The fragility was in the lock's release path, the case where a leader stops without releasing cleanly, which the company calls "precisely the kind of edge that is easy to miss in review and under-covered by tests." It did not catch it at either stage.

The company lists its actions. It says it has added alerting on notification throughput, fixed the code so that a lock held by a stopped leader is reliably released and picked up by another process, and added tests around the configuration and integration tests to show that an orphaned lock can be obtained by another process. It says it is reviewing how it handles support tickets that describe an absence of expected behavior.

The company's own word for the failure is an absence. Which of a reader's own systems would raise an alarm if it simply stopped?