Hours since the last /upload/listings drop Alibris ack’d. Stale = feed cycle broken.
At a glance
Hours since the last /upload/listings outbound file Alibris confirmed via ack. Stale (>48h) means the feed cycle is broken; every listing edit since the last ack is queued and unsynced. The single most important operational health-check for the Alibris connection.
Calculation
Calculated automatically from your Alibris 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 US bookseller, 32,100 active Alibris listings, 4-hourly outbound feed cycle. Snapshot 01 May 26.
When the alert fires at 56.4h, four immediate operational consequences:
Six things to notice that are specific to Alibris and the Pure-FTPd feed model:
- Pure-FTPd credential rotation is silent and the #1 cause. Alibris occasionally rotates the Pure-FTPd account password without prior notice; if your connector config has the old password, uploads fail with a TLS-handshake error that doesn’t propagate to most monitoring. Rotate credentials proactively quarterly.
- Alibris’s processing window is 02:00 to 06:00 PST nightly. During this window, ack files lag by 2 to 4 hours even on healthy connections. A 4-5h reading at 09:00 PST is normal; the same reading at 16:00 PST is a problem.
- Network connectivity issues at the merchant data centre are the second cause. ISP outages, firewall rule changes, DNS misconfigurations all break Pure-FTPd connections. Maintain monitoring on the outbound network path; this card is the catch-all but a network-layer probe catches the issue 1 to 2 hours sooner.
- The 4-hourly upload cycle is the sweet spot. Hourly uploads hit Alibris’s rate-limit on busy accounts; daily uploads create a 24-hour minimum staleness floor; 4-hourly balances throughput and Alibris’s processing capacity. Most successful booksellers run 4-hourly.
- Disk-full on outbox staging is a sneaky cause. Outbox files queue up; if your monitoring doesn’t include disk usage, the first symptom is feed staleness here. Set a disk-usage alert at 80% on the outbox volume.
- The 7-day silent failure scenario is the worst case. A bookseller running a hands-off setup who only checks revenue weekly may not notice for a full week; by then the queued backlog is enormous, the catalogue is stale on thousands of listings, and recovery requires phased re-uploads to avoid Alibris-side rate limits. Always alert on this card.
Sibling cards merchants should reference together
Last Successful Upload is the connection-health metric. Pair with these:Reconciling against the vendor’s own dashboard
Where to look in the Alibris seller dashboard: Alibris’s UI does not publish a “last upload age” view; this card is the canonical reading. Indirect cross-checks:- Sellers → Inventory → Upload History. Lists recent uploads with timestamps; the most recent confirmed entry is the data this card derives from.
- Sellers → Inventory → Manage. Spot-check a listing you recently edited; if the Alibris UI shows the OLD state, the change hasn’t propagated.
Cross-connector reconciliation:
Known limitations / merchant FAQs
My reading is 56h. What do I do in the next 30 minutes? (1) Test Pure-FTPd login manually with the connector’s stored credentials. (2) Check the outbox staging directory for queued files. (3) Open Alibris’s developer status page for known platform-side issues. (4) If credential expired, rotate; if network, work with your data centre; if Alibris-side, wait and document. Why does Alibris not warn me when my feed is stale? Alibris does send weekly batch emails on persistent failures, but the cadence is too slow to act on. This card’s 48h threshold catches the issue 5 to 6 days before Alibris would email you. ISBN match quality, can it cause silent feed failure? Yes. Severely malformed feed rows (e.g. ISBN field containing a tab character) can cause Alibris to silently reject the entire file, no ack returned. The signature is “card crosses 48h after a recent inventory data refresh”. Multi-marketplace, can a single network issue trip both Alibris and AbeBooks staleness? Yes, if the cause is at the merchant data centre (DNS, ISP, firewall). Co-stale alerts confirm merchant-side cause; single-marketplace alerts are usually marketplace-specific. Listing-quality / Buy Box impact, what’s the recovery time? Once feed is restored, the catalogue propagates Alibris-side within 4 to 24 hours; ranking decay reverses over 7 to 14 days; cancellation-rate impact takes 30 days to age out. Inventory-sync lag during stale feed, what’s the right behaviour? Two strategies: (a) Conservative - manually mark all Alibris listings as out-of-stock via Alibris UI to prevent stockout cancellations; (b) Permissive - leave listings live, accept stockout cancellations, recover post-restoration. Most booksellers under 1,000 daily orders use (b). Rare books vs commodity, does staleness hurt them differently? Commodity books bear most of the operational damage (high volume = many stockout cancellations during stale-feed). Rare books rarely produce same-day stockouts (low velocity); the staleness damage to rare is more about opportunity cost (new listings not surfaced). When does the card update vs my action? Card recomputes every 4 hours. After a successful upload-and-ack cycle resumes, the card updates to the current(NOW - latest_ack_timestamp) value at the next refresh. Don’t expect immediate clearing.
Why is 48h the threshold and not 24h?
Because Alibris’s daily processing window can legitimately produce 12 to 24h staleness on healthy connections. 48h is the point where it’s clearly NOT just normal Alibris-side processing lag. Booksellers running 4-hourly cycles often configure a tighter 12 or 24h alert threshold.
Can I monitor this in real time without Vortex IQ?
Yes; tail your outbox staging directory and check ack-file mtimes against the most recent outbound. The card automates this and adds the cross-marketplace and historical context.