Triggered when /outbox/listings has no confirmed ack in 48h, feed is blind, all listing changes stuck.
At a glance
P1 alert. Fires when the AbeBooks outbound listings feed (/outbox/listings) has not received a confirmed ack from AbeBooks in 48 hours. While the alert is active, every listing edit (price change, stock change, condition update, new listing, delete) is stuck in a queue with no path to AbeBooks. The catalogue is frozen on whatever state the last successful cycle left it in.
| What it counts | Boolean alert state, 1 if time_since_last_acked_outbox_upload > 48h, else 0. Maintains a list of queued-but-undelivered outbox files for visibility (count + total bytes + first-failed timestamp). |
| API endpoint + report | Derived from the FTPS connector’s last-successful-ack heartbeat. Vortex IQ polls the AbeBooks FTPS server’s /inbox/acks directory every 4 hours; if no fresh ack appears for 48h after an outbound upload, the alert fires. |
| Severity | P1. Every hour the alert is open, the merchant is operating blind on AbeBooks. The only catalogue state AbeBooks sees is the last-acked snapshot. New stock isn’t surfaced; sold-out listings are still sellable; price changes don’t propagate. |
| What “feed is blind” means in practice | (1) New books added in your inventory tool stay invisible on AbeBooks. (2) Books that sold on Alibris/Amazon/DTC stay listed (and orderable) on AbeBooks, every order is a stockout cancellation. (3) Repricer changes don’t apply, your prices freeze. (4) Listings flagged for delete stay live. |
| Fees / commission | Not applicable directly to the alert. Indirect commission impact: every stockout cancellation triggered by frozen-feed counts toward your seller-error cancellation rate (3% threshold for review). |
| Refunds / cancellations | Not directly. But the alert’s downstream effect drives a cancellation spike, watch Cancellation Rate during and 7 days after. |
| Currency | Not applicable. |
| Common root causes | (1) FTPS credential rotation at the merchant’s hosting provider not reflected in the AbeBooks connector config (~32% of incidents). (2) AbeBooks-side maintenance window that overran (~22%). (3) Network connectivity loss from the merchant’s data centre to AbeBooks’s FTPS host (~18%). (4) Outbound file format violation that AbeBooks silently rejects without acking (~15%). (5) Disk-full or quota on the merchant’s outbox staging directory (~9%). (6) Other (~4%). |
| Multi-marketplace overlap | Each marketplace runs its own feed; an AbeBooks feed failure typically does NOT affect Alibris or Amazon. The exception: if the cause is merchant-side credential rotation or a network outage at the merchant data centre, all three feeds may fail together. |
| Time window | RT (real-time alert state). |
| Alert trigger | no successful upload >48h. |
| Roles | owner, operations, engineering. |
Calculation
Calculated automatically from your AbeBooks data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK independent bookseller, 38,400 active AbeBooks listings, daily outbound feed cycle. Incident timeline 28 Apr 26 to 01 May 26.| Timestamp (UTC) | Event | Operational consequence |
|---|---|---|
| 28 Apr 04:00 | Last successful outbox upload + ack | Catalogue snapshot frozen at this state |
| 28 Apr 04:00 to 30 Apr 04:00 | Daily upload cycle attempts continue, no ack from AbeBooks | Files queued in outbox; no visible failure to merchant |
| 30 Apr 04:00 | Alert threshold crossed (48h since last ack) | Card fires |
| 30 Apr 09:14 | Ops team paged, investigation starts | - |
| 30 Apr 11:32 | Root cause identified: FTPS host’s TLS certificate rotated 27 Apr; connector still using old cert chain | Stockout cancellations: 14 between 28 Apr and 30 Apr |
| 30 Apr 12:48 | Connector config updated with new TLS root cert; reconnect succeeds | First successful upload acked |
| 30 Apr 13:14 | Backlog of 3 daily files (28, 29, 30 Apr) re-uploaded and acked | All catalogue changes propagate to AbeBooks |
| 30 Apr 14:02 | Card clears; cancellation-rate effect persists for 7 days | - |
| Impact dimension | Value |
|---|---|
| Listings frozen (no edits propagated) | 38,400 |
| Stock changes queued (sold on Alibris/Amazon/DTC, still live on AbeBooks) | 412 |
| Stockout cancellations triggered as a direct result | 14 |
| Repricer updates queued | 9,840 |
| Estimated revenue impact (lost sales + cancellation-rate damage) | £1,450 |
| Cancellation rate impact for 30D rolling window | +1.1 percentage points |
- 48 hours is the standard threshold but not the only one to use. A bookseller running a daily feed cycle should alert at 48h; a bookseller running a 4-hourly cycle should alert at 12h or 24h. Tune the threshold to your actual feed cadence; default catches the daily-cycle audience.
- The “queued, no ack” signature is the most common version of feed failure. AbeBooks’s FTPS server doesn’t send error responses to most failure modes; it just drops the connection or stops processing. Detection is by ABSENCE of ack, not by error message. This is why the threshold is time-based rather than error-count-based.
- TLS certificate rotation is the #1 cause and the most preventable. Merchants using their own outbound FTPS client should subscribe to AbeBooks’s developer mailing list for advance notice of certificate rotations (typically 30 days advance notice for planned rotations, 0 days for emergency rotations). Vortex IQ’s connector handles cert pinning automatically, but custom feed clients often miss this.
- Stockout cancellation cascade is the second-order damage. During the 56h outage, 412 books sold on other channels were still listed as available on AbeBooks. Of the 14 that buyers attempted to purchase on AbeBooks, every one resulted in a stockout cancellation, which counts toward the 3% cancellation threshold. A 56h outage during a busy week can wipe out 30 days of careful cancellation-rate management.
- The 30 to 90 day reputational tail. AbeBooks’s seller-standing tile averages cancellation rate over 30 days. A 14-cancellation cluster during this outage will sit in the 30D average for the next 30 days; expect the seller-standing tile to show “at risk” until early Jun 26.
- The 9,840 queued repricer updates are interesting. Most of those are routine 1 to 5 pence pricing nudges that don’t matter individually, but in aggregate they represent the catalogue tracking the live market. Letting them queue and fire all at once after the outage causes a one-day price-change spike that some buyers notice; a phased re-upload (1,000 listings/hour) is gentler.
Sibling cards merchants should reference together
Feed cycle failure is the P1 operational alert. Pair with these to triage and recover:| Card | Why pair it with Feed Cycle Failure |
|---|---|
| Last Successful Upload | The companion card. While the alert is firing, this card shows exactly how long ago the last good cycle was. |
| FTPS Connection / Auth Health | The first thing to check on alert. Auth failures are the leading cause of feed failures; a 3+ consecutive auth-failure pattern usually precedes feed failure by 4 to 24h. |
| Failed Batches (7d) | The 7-day history view. If failed-batch count was already elevated before this alert, you have a chronic feed-quality issue, not a one-off outage. |
| Top Upload Error Types | Cause attribution. After resolving the feed connection, the queued backlog will surface any format violations as soon as it processes; pre-empt by checking error patterns. |
| Inbound Orders File Lag | Cross-direction check. Many feed-failure causes (network, DNS, FTPS host outage) affect both inbound and outbound; if both are alerting, the issue is platform-wide not file-specific. |
| Cancellation Rate | Downstream impact. The stockout-cancellation cascade during the outage shows here over the following 7 to 30 days. |
| Suspended Listings | Downstream impact. Backlogged outbox files often surface format violations on processing; expect a small bump in suspensions when the queue drains. |
| Alibris Feed Cycle Failure | The peer-marketplace alert. If both fire simultaneously, the cause is merchant-side (network, credentials at your data centre); if only one fires, it’s marketplace-specific. |
Reconciling against the vendor’s own dashboard
Where to look in the AbeBooks seller dashboard: AbeBooks’s seller dashboard does NOT publish a feed-health view; the merchant typically only learns of a feed failure via downstream symptoms (drop in revenue, spike in cancellations). Three indirect views help triangulate during an active alert:- My AbeBooks → Inventory → Upload History. Shows the last N upload attempts AbeBooks recorded; if the most recent entry is >48h old, AbeBooks confirms it has not received your files.
- My AbeBooks → Inventory → Manage. Spot-check any listing you know you’ve recently edited; if the AbeBooks UI shows the OLD price/stock/condition, the change hasn’t propagated.
- AbeBooks Developer Status Page (when available; intermittent service). Lists known platform-side outages.
| Reason | Direction | Why |
|---|---|---|
| AbeBooks-side ack delay | Card alerts but feed is fine | Occasionally AbeBooks’s processing pipeline backs up and acks land 12 to 36h after the actual upload. The card sees no ack and alerts; AbeBooks has the file. The 48h threshold is calibrated to be longer than typical AbeBooks-side delays, but 99th-percentile delays can trip false alerts. Wait one cycle before treating as P1. |
| Connector polling cadence | Card alerts 4h late | Vortex IQ polls the AbeBooks ack directory every 4 hours; an ack landing 30 minutes after a poll is detected up to 4 hours later. Real outages last days, not hours, so this rarely matters. |
| Outbox-empty edge case | Card silent during quiet period | If the merchant has no listing changes to upload for 72 hours (genuinely static catalogue), there’s no outbound file and no ack to expect; the card stays silent. The “no ack >48h” threshold only applies when there IS an outbound file pending. |
| Manual upload via AbeBooks UI | Card unaware | If the merchant or staff manually uploads a CSV via the AbeBooks website (bypassing the FTPS feed), AbeBooks acks it but the connector doesn’t see the ack. The card stays in alert state until the next FTPS cycle resolves. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
alibris.al_alert_feed_failure | Independent feeds. Each marketplace has its own FTPS host and credentials. | Co-firing alerts strongly suggest merchant-side cause (network, DNS, expired credentials at your data centre). Single-marketplace alerts are usually marketplace-specific. |
amazon.amzn_alert_feed_failure | Different protocol. Amazon uses MWS / SP-API, not FTPS, so the failure modes don’t share root causes. | Amazon can fire its own feed alert from rate-limit, schema-validation, or auth-token expiration; AbeBooks rarely sees these failure modes. |
shopify.alert_webhook_failure | Inverse direction. Shopify pushes to you (webhooks); AbeBooks polls from you (FTPS). Different mechanic entirely. | Shopify webhook failures don’t propagate to AbeBooks at all. |