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.
| What it counts | (NOW - max(timestamp of last confirmed-ack file in /download/acks)), expressed in hours. Tracks only confirmed acks, not upload attempts (an upload that landed without ack is treated as not-yet-confirmed). |
| API endpoint + report | Polled from Alibris’s Pure-FTPd /download/acks directory every 4 hours. Each ack file confirms one outbound /upload/listings file received and processed. |
| ISBN vs account scope | Account-level. Tracks the connection health, not per-listing. |
| Listing-quality impact | Indirect but severe when stale. A 48h+ unconfirmed feed means new listings, price changes, condition updates, stock changes are all stuck. Alibris is operating on the previous catalogue snapshot. Compounding effect on stockout cancellations, listing freshness, and pricing accuracy. |
| Fees / commission | Not applicable directly. Indirect: stockout cancellations from frozen feed contribute to seller-error cancellation rate; persistent failure suppresses search rank, reducing commission paid to Alibris. |
| Refunds / cancellations | Not applicable. Downstream: feed staleness drives cancellation cascade. |
| Currency | Not applicable. |
| Healthy ranges | <24h is excellent; 24 to 48h is degraded but operational; >48h is broken. Most booksellers should target <12h via 4-hourly upload cycles. |
| Common causes of staleness | (1) FTPS credential expired, ~30%. (2) Network connectivity issue at the merchant data centre, ~22%. (3) Alibris-side processing delay, ~18%. (4) Outbound file format error silently dropped, ~16%. (5) Disk-full on outbox staging, ~10%. (6) Other, ~4%. |
| Multi-marketplace overlap | Each marketplace has its own feed; staleness on Alibris doesn’t directly imply staleness elsewhere unless the cause is merchant-side (network, credentials at your data centre). |
| Time window | RT (live; recomputes every 4 hours). |
| Alert trigger | >48h since last confirmed. |
| Roles | owner, operations, engineering. |
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.| Snapshot reading | Card value | Status |
|---|---|---|
| Healthy steady state | 3.8h | All recent uploads confirmed |
| After typical Alibris slow processing | 7.2h | Mild lag, normal Tuesday morning |
| After 12-hour Alibris-side outage | 14.6h | Degraded but recovering |
| After credential expiry (Sat - Mon morning) | 56.4h | Alert firing, feed broken since Sat |
| After 7-day silent failure | 168h+ | P0 incident; thousands of edits queued |
| Consequence | Magnitude |
|---|---|
| Listing edits queued in outbox | ~340 (typical 4-hourly cadence x 14 cycles) |
| Stock changes not propagated | ~140 |
| Stockout cancellations triggered | ~6 |
| Estimated revenue impact | 880 |
- 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:| Card | Why pair it with Last Successful Upload |
|---|---|
| Feed Cycle Failure (alert) | The escalation. When this card crosses 48h, the feed-cycle-failure alert fires. |
| Failed Batches (7d) | If recent uploads succeeded but failed batches are climbing, the cause is data quality not connectivity. |
| FTP Connection / Auth Health | Auth failures precede feed failures by 4 to 24h. |
| Inbound Orders File Lag | Cross-direction check; merchant-side issues hit both. |
| Suspended Listings | Downstream consequence; backlogged uploads surface format violations on processing. |
| Cancellation Rate | Stockout cascade during stale-feed periods shows here within 7 days. |
| AbeBooks Last Successful Upload | Cross-marketplace; co-failures point to merchant-side network/DNS. |
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.
| Reason | Direction | Why |
|---|---|---|
| Polling cadence | Card lags up to 4h | Vortex IQ polls the ack directory every 4 hours; an ack landing 30 minutes after a poll is detected up to 4 hours later. |
| Alibris processing lag | Card lags during Alibris’s nightly processing | 02:00 to 06:00 PST is Alibris’s batch window; reading is artificially elevated for a few hours each morning. |
| Manual upload via UI | Card unaware | Manual CSV uploads via the Alibris website don’t generate Pure-FTPd acks; this card stays on the FTPS-only timeline. |
| Outbox-empty edge case | Card meaningless | If you haven’t uploaded any edits in the last several hours, no ack was due; reading reflects last actual upload, not last possible upload. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
abebooks.ab_last_successful_upload | Independent feeds. | Cross-failures point to merchant-side network. |
amazon.amzn_last_successful_feed | Different protocol (SP-API). | Amazon’s failure modes don’t share root causes with Alibris FTPS. |
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.