Crisp's postmortem timestamps the hour a vendor's hardware failed

The workload

Crisp, the support-chat vendor this site already covers for pricing, is itself a dependency a founder using it has to monitor, and Crisp's own incident record is the primary document for understanding what that monitoring should watch for. On 22 July 2019, a hardware failure at Crisp's infrastructure provider triggered two outages of roughly 30 minutes each, and Crisp's co-founder wrote up the cause and response in detail rather than leaving it to a status-page line item.

What the documents show

Verified: Crisp's own incident write-up, published 23 July 2019 by co-founder Baptiste Jamin, states the root cause as a DigitalOcean hardware failure affecting a server hosting Crisp's SSDB database, first detected by Crisp's own open-source Vigil monitoring system at 13:14 UTC. Verified: the same post gives a specific timeline, DigitalOcean acknowledging the issue at 13:34 UTC, a failed automatic server rebuild, and a subsequent “hot” migration that DigitalOcean had scheduled and that unexpectedly caused slow disk I/O, cascading into the API system roughly 20 minutes later. Verified: Crisp's live status page confirms the current monitoring architecture the incident post describes, tracking web nodes, relay nodes, platform nodes, data storage nodes and mailer nodes separately by latency, the same micro-service breakdown the 2019 post uses to explain why some Crisp features stayed up while others failed.

The operating cost

Verified: the post states two downtimes of approximately 30 minutes each on 22 July 2019, with no dollar cost stated, only the technical and process changes Crisp says it made afterward. The post states the detection-to-escalation window explicitly, an alert to Crisp's team on Slack immediately, escalating to phone calls if unresolved after five minutes, which is the workload a founder relying on Crisp inherits indirectly: five minutes is Crisp's own internal tolerance for silence before escalating, not a number the founder controls.

The stop condition

The post does not state a point at which Crisp considered the incident fully closed beyond describing planned infrastructure hardening. Editorially: for a founder depending on Crisp, the more relevant stop condition is not Crisp's own remediation timeline but a personal one, the point at which repeated or unresolved incidents on a vendor's status page justify evaluating an alternative, a threshold this entry does not set because the cited documents describe only this one incident.

• Does the vendor's own postmortem name a root cause outside their control, or something they could have architected around?
• How long after detection did the vendor's own alerting escalate, and is that fast enough for the workload it protects?
• Has this specific failure mode recurred since, based on the vendor's own subsequent status history?

A vendor that publishes a detailed postmortem, naming times, causes and a third-party provider, gives a founder more to evaluate than a status page showing only “all systems operational”; the 2019 incident is one dated data point, not a verdict on Crisp's reliability today.