slatepipe operational

Status › Incident history

Incident history

Everything that has taken a Slatepipe component off its normal behaviour, newest first. Each entry keeps the timeline it had while it was open, states and all, so the write-up is the same one the on-call saw.

Logged here7
Last 90 days4
Open now0
Longest, 202648 min

Alert emails delayed about six minutes

resolved9 Oct 2026

Affected: alert delivery

  • 05:41 UTC
    investigating
    Two failure alerts for the demo collector were acknowledged late; the relay queue was backing up.
  • 05:44 UTC
    identified
    The upstream SMTP relay was rejecting on a stale TLS session and the collector was retrying on the ninety-second schedule.
  • 05:47 UTC
    resolved
    The relay recovered on its own; both queued messages left within one retry. Webhook delivery was never affected.

Nightly prune held the runs-table lock

resolved20 Sep 2026

Affected: collector, interface

  • 04:17 UTC
    investigating
    The dashboard went blank for the duration of the 04:17 prune; reads timed out against the statement limit.
  • 04:22 UTC
    identified
    Event-payload deletion was taking an exclusive lock on runs for roughly eighty seconds on a 1.4 GB database.
  • 04:40 UTC
    monitoring
    Prune was moved off the hour and reads returned; a batched delete that does not hold the lock was staged for the next patch.
  • 05:05 UTC
    resolved
    The 0.14.2 build ships the batched prune and the nightly pass now finishes in about eleven seconds.

Run detail loaded the stderr tail twice on slow links

resolved2 Sep 2026

Affected: interface

  • 11:08 UTC
    investigating
    A support customer on a satellite link reported the run page hanging before the error tail appeared.
  • 11:40 UTC
    identified
    The page requested the 64 KB tail once for the summary and once for the detail pane, doubling the transfer.
  • 12:30 UTC
    resolved
    Fixed in 0.14.1; the tail is fetched once and shared between the two panes.

Baseline cache rebuild blocked ingest during the 0.14.0 upgrade

resolved17 Aug 2026

Affected: collector, database

  • 02:00 UTC
    investigating
    Agents began spooling to disk immediately after the collector was upgraded to 0.14.0.
  • 02:03 UTC
    identified
    The migration rewrites the baseline cache, and on this install that is about four minutes of write-heavy work that stalled new inserts.
  • 02:09 UTC
    resolved
    The rewrite finished, the spool replayed in order and no run was lost. The upgrade note now warns that the pass runs about a minute per million runs.

Duplicate alerts with two collectors on one database

resolved24 May 2026

Affected: collector, alert delivery

  • 22:14 UTC
    investigating
    A failing pipeline sent two of every alert after a second collector was added behind the load balancer.
  • 23:10 UTC
    identified
    De-duplication was kept in each collector's memory rather than shared, so both evaluated the same failure.
  • 00:02 UTC
    resolved
    0.13.0 moves de-duplication into the database behind a unique constraint; one failure now sends one message.

Spool ceiling reached during a long collector outage

resolved15 Nov 2025

Affected: agents

  • 19:30 UTC
    investigating
    The collector host was down for a planned database move that ran long, and agents kept queuing events to disk.
  • 21:00 UTC
    identified
    Three busy hosts crossed the 256 MiB spool ceiling and began dropping their oldest events first, as designed.
  • 08:40 UTC
    resolved
    The collector came back, the spools replayed and the dropped-event counter reported the gap. The history shows a hole, not a silent loss.

Client-side interface retired for server-rendered pages

resolved10 Aug 2025

Affected: interface

  • 00:00 UTC
    monitoring
    The single-page interface had become impossible to debug on customer networks and was scheduled for replacement.
  • 00:00 UTC
    resolved
    0.10.0 serves plain server-rendered pages; the read-only interface has had no client framework since.