Operations
How nohold surfaces operational health and what to do when something needs attention.
How nohold surfaces operational health and what to do when something needs attention.
Reconciliation health card (Growth+)
On the Overview page, the Reconciliation health card surfaces four counts that indicate something needs attention:
| Count | When it's non-zero |
|---|---|
| Splits stuck pending | Splits in pending status with split_at more than 24 hours ago. Means the split worker started but never finished. |
| BP sales orders missing | Splits older than 1 hour with both bp_immediate_order_id AND bp_deferred_order_id NULL, but Brightpearl credentials ARE connected. Means the BP write should have happened but didn't. |
| Dead dispatches | Outbound dispatches our queue gave up on after the retry budget was exhausted. |
| Stale holds | Fulfillment holds older than 30 days still in held status. Means either a classifier-config gap or Shopify-side state divergence. |
All four counts are per-merchant. If any is non-zero, the badge turns red (N need attention) and the corresponding rows turn red. Colorblind-safe: the text changes too, not just the color.
When everything is zero, the badge is green (All clear). The card still renders; silence isn't the right signal when this is your only proactive ops indicator.
A merchant who hasn't connected Brightpearl yet doesn't see the BP sales orders missing alarm spuriously; that count is gated on credential presence.
The sweeper
nohold runs a background sweeper that periodically recovers stuck work and fires the 30-day FTC notice. It handles:
- Webhook deliveries that started processing but never completed.
- Outbound dispatches that didn't get picked up or didn't finish.
- Billing-cycle resets when a merchant's anniversary rolls over.
- Trial expiry when a merchant's 14 days are up.
- The FTC 30-day delay notice for preorders open more than 30 days without a confirmed ship date and without a customer cancel request.
The sweeper is idempotent. A row can't be re-claimed or double-processed by a second invocation. You don't have to trigger anything; it runs in the background and is what catches most transient infrastructure hiccups before they're visible to you.
What if the dashboard health card always shows red?
A few rows in any of these counts is normal: a customer who never replies to a cancel email leaves a stale hold; a Brightpearl outage at midnight leaves dead dispatches. The card's job is to surface signal, not to demand zero.
Worth investigating when:
- Splits stuck pending > 5. Likely a split-worker config issue (Shopify token expired, scope revoked, classifier choking on a malformed order).
- BP sales orders missing > 5. Brightpearl outage or auth issue.
- Dead dispatches > 0. Always worth a look. Dead means the queue gave up; the failure didn't recover on its own.
- Stale holds > 10. Likely a campaign that's been forgotten or a Shopify-side state divergence. Worth a manual audit.
Email support with the specific count and we'll dig in. For dead dispatches, include the split's order number; we can usually pinpoint the issue from the dispatch row.
What about the dispatch DLQ?
When a dispatch exhausts its retry budget, the row lands in the internal dead-letter queue (DLQ). Currently the DLQ is internal-only; there's no merchant-facing UI. We monitor it and proactively reach out if your merchant ID shows up.
A merchant-facing DLQ view is on the V2 list.