Hours since the last successfully-parsed inbound file. >36h on a working day = something has stopped.
At a glance
Hours elapsed since the supplier’s Costco SIP integration successfully parsed an inbound file from Costco’s/inboxSFTP folder. Costco drops EDI 850 (Purchase Order), EDI 860 (PO Change), EDI 820 (Remittance Advice), EDI 997 (Functional Acknowledgement) and item-master sync files into/inboxon a near-daily cadence; the supplier’s integration polls, downloads, parses, and writes to the local datastore. This card is the supplier’s only systematic visibility into “is my Costco link still alive”. A green dial means the link is live; a red dial means the supplier is flying blind on every other Costco card.
Calculation
Calculated automatically from your Costco SIP data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
The same US household-goods supplier on Costco SIP. Reading taken at 09:00 PT on Tuesday 10 Mar 26.
The card fires warn at the 36-hour mark on Wednesday morning. Five things to notice:
- A 36-hour gap on a working day means something has stopped. Costco’s inbound cadence is reliable enough that 36 hours of silence is rarely a Costco-side problem; it is almost always a supplier-side issue: SFTP credential expired, EDI translator job stopped, integration server out of disk, scheduled maintenance forgot to set the pause flag.
- Triage order: connectivity → translator → datastore. (1) Test SFTP connectivity (
sftp supplier@sftp.costco.com); if connection fails, IP allowlist or credential issue. (2) Test EDI translator queue depth; if backed up, translator is hung. (3) Test datastore writes; if writes fail, integration ingested files but cannot persist them, the dial reads stale. - Working-day exclusion matters. Tuesday morning at 09:00 with last-successful Friday at 17:45 = roughly 60 elapsed hours but only roughly 16 working-day hours; the alert correctly does not fire. On the same Tuesday at 21:00 with last-successful Friday at 17:45 = roughly 28 working-day hours; still inside threshold. Without the working-day exclusion the alert would fire every Monday morning, which is operational noise.
- A “green-but-stale-business-data” failure mode exists. If the SFTP feed is healthy and ingesting 997 ACK files but Costco has stopped sending 850 POs (Costco-side commercial pause, not technical), this card stays green while Daily PO Count drops to zero. Pair the two for full coverage.
- The dial typically reads 0 to 16 hours on weekdays. Anything above 24 hours on a working day deserves a glance even if not alerted; persistent 24 to 30 hour readings suggest the inbound cadence is degrading toward a future outage.
Sibling cards merchants should reference together
Last Successful Inbound is the integration-liveness dial. Pair with these:Reconciling against the vendor’s own dashboard
Where to look in Costco’s own portal: Costco Supplier Portal → EDI → Outbound Files (from Costco) lists every file Costco’s gateway dropped to the supplier’s /inbox in chronological order. The most recent timestamp here should match what this card reads. If the portal shows files Costco believes were delivered but the card has not seen them, the SFTP layer between Costco’s gateway and the supplier’s ingest is the failure point. Why our number may legitimately differ from Costco’s portal:
Cross-connector reconciliation:
Known limitations / merchant FAQs
The dial reads 36 hours and rising. What is the playbook? In order: (1) Test SFTP connectivity tosftp.costco.com from the supplier’s integration host; auth failure or network timeout points to credential or IP allowlist. (2) Check EDI translator queue depth; backed up = translator hung. (3) Check datastore writes; if the integration ingested files but cannot persist, dial reads stale. (4) Check Costco supplier portal for declared maintenance windows or system advisories. (5) Open a ticket with Costco’s supplier-portal helpdesk if (1)-(4) do not explain it.
Why does the dial sometimes read 50+ hours over a weekend without alerting?
Working-day exclusion. Costco’s inbound traffic is weekday-only; a Friday 17:45 last-successful followed by a Monday 09:00 read is roughly 64 elapsed hours but only 0 working-day hours over the threshold. The alert correctly does not fire; the operations team does not need to be paged on Sunday morning.
The dial dropped from 30 hours to 0 minutes overnight, but only one file landed. Is that real?
Yes. A single successful parse advances the dial to 0; the card is “hours since last success”, not “files in last hour”. A single 997 ACK file at 03:00 resets the dial; whether that single file is the right business content is a separate question (use Daily PO Count and Sync Error Count to confirm).
Costco’s portal shows files were delivered last night but the card has not advanced. What now?
SFTP-to-ingest gap. Three possibilities: (1) SFTP poll has stopped. The integration’s SFTP poller may have crashed; check logs. (2) Parse failure on every file. Files arrived but all hit a parse error; check Sync Error Count (7d). (3) Timezone misalignment. Costco’s portal shows files in PT and the card in UTC; verify the timestamp conversion before declaring an outage.
Should I configure a separate alert per file-type?
Reasonable for higher-stakes operations. The default alert tracks any successful parse. For higher-stakes setups, configure secondary alerts: “no 850 in 24h on a working day” (catches Costco-side commercial pause), “no 997 in 4h after every 856 sent” (catches Costco-gateway parse failures), “no item-master sync in 36h” (catches catalogue staleness). The default keeps the dial simple; the secondary alerts catch specific failure modes.
The dial reads 5 minutes but our PO count is zero. Is the integration fine?
Technically yes (link is live), business-wise no (Costco is not sending POs). This is the “green-but-stale-business-data” failure mode mentioned in the worked example. Common causes: (1) Costco-side commercial pause (compliance issue, supplier under review, payment dispute), (2) seasonal seasonality (post-Christmas Costco PO cadence drops dramatically until mid-Feb), (3) buyer transition (the supplier’s primary buyer has left and the replacement has not yet picked up the file). Pair with Daily PO Count for the business-content check.
Can I see file-by-file ingest logs?
Yes, via the drill-down. The card surfaces a sortable table of all ingested files in the last 30 days with filename, received_at, parsed_at, file_type, parse_status, business_content. Use this to verify cadence and identify any specific file that broke the integration.
Is there a cost to this dial firing during maintenance?
Only operational noise; the alert pages the on-call ops engineer. Always set the integration to paused state during planned maintenance windows so the alert does not fire. Pause windows are visible on the integration audit log and do not advance the dial.
The card reads 0 hours but a colleague says EDI files are not flowing. Who is right?
Check the most recent file timestamp directly. If the dial reads 0 hours because a 997 ACK landed minutes ago but no 850 PO has arrived in 36 hours, the colleague is right about business content and the dial is right about technical liveness. Both signals are useful; they answer different questions. The 0-hour reading is reassuring on the integration plumbing; the missing 850 traffic is concerning on Costco’s commercial behaviour.
My ops team uses PagerDuty. Can the alert route there?
Yes. The Vortex IQ alert framework supports PagerDuty webhook delivery. Configure once at integration level; same trigger that lights up this card sends to PagerDuty with the appropriate severity. Most ops teams configure this card’s red state as P2 (warn) escalating to P1 (critical) if not acknowledged within 15 minutes.