Proof — evidence, not testimonials

These are the current production check results for Merlonix’s own surface, served by the same public status-page machinery every tenant gets — not a screenshot, not a narrative.

Fetching live check results…

Our own monitor paged us — and the postmortem made the detector better

Situation

Merlonix runs its own scheduled workers — including the poller that ingests third-party vendor status feeds — under the same heartbeat monitoring we sell. To cut cost while pre-revenue, that poller was moved from a 5-minute to an hourly cadence.

Signal

The heartbeat monitor raised a high-severity "worker stalled" escalation about 20 minutes after a beat — paging the operator about a worker that was actually healthy and simply between hourly runs.

Response

The session-start production error audit caught the contradiction: the run ledger showed the worker completing successfully mid-cycle. Root cause: when the cadence changed, the monitor’s grace window was never updated — a cadence-change vs monitor-config drift.

Outcome

The grace window was aligned to the real cadence and the false page was resolved with a recorded root cause. When the same failure class surfaced on a sibling worker in July, it was closed at the root: the heartbeat write was decoupled from an internal throttle so a healthy worker cannot trip the window again. The class — monitor config drifting from the thing it monitors — now has a named entry in our audit checklist.

398 queued-job failures, one root cause — found by our own error audit

Situation

AI-assisted vendor summaries run through a multi-provider chain with a deterministic fallback. Failed jobs land in a dead-letter queue, and each overflow opens an operator escalation.

Signal

A standing production error audit found the escalation ledger saturated: hundreds of open rows, 100% of them the same dead-letter-queue overflow code — a volume that would have masked any other real failure.

Response

Tracing the chain showed the free-tier provider keys had gone stale, so every request fell through to an exhausted paid leg and failed permanently. Two latent defects compounded it: a retired model id and a router that threw instead of engaging the deterministic fallback. All three were fixed, and 398 accumulated escalations were resolved with the root cause recorded.

Outcome

The escalation ledger returned to zero open rows, verified end-to-end on the next scheduled run. The error audit that caught it is now a standing step at the start of every engineering session, and the fallback path is covered by tests so a provider outage degrades gracefully instead of queueing failures.

Turning on deep observability surfaced seven real production issues

Situation

Merlonix’s five queue and cron workers originally logged only to the edge platform’s ephemeral logs — errors there were invisible unless someone happened to be watching.

Signal

Wiring structured error tracking and log forwarding into all five workers immediately surfaced seven real production issues that had been occurring silently.

Response

Each surfaced issue was triaged and root-caused through the normal fix-ledger process rather than patched blind.

Outcome

Every background worker now ships errors and structured logs to the same observability stack the API uses, so a silent failure class cannot re-form. The episode is why we tell customers that "no alerts" only means something when the alerting path itself is monitored.

None published yet — and that’s deliberate. A customer story appears here only with the customer’s written consent, a named consent record, and the same Situation → Signal → Response → Outcome → Evidence structure as our first-party write-ups. We’d rather show you our own incidents than invent yours. If you’re a customer with a story worth telling, we’d love to write it up with you.