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.
| What it counts | now() - max(inbound_file.successfully_parsed_at) in hours, where successfully_parsed_at is the timestamp of the last file the supplier’s integration ingested without a parse error. |
| File-types included | EDI 850 (PO), EDI 860 (PO Change), EDI 820 (Remittance), EDI 997 (Functional ACK), item-master sync. The card uses any successful parse as evidence of liveness; even a 997 ACK file (which has no business content) confirms the SFTP and EDI translator are working. |
| Cadence baseline | Costco’s typical inbound cadence: 850 PO files Mon-Fri evening (US Pacific time), 860 PO Change ad-hoc, 820 Remittance weekly Friday, 997 ACK within 4 hours of every outbound 856 ASN, item-master sync daily overnight. On a normal working day a supplier sees 4 to 12 inbound files. |
| Working day vs weekend | The 36-hour alert threshold is calibrated to working-day cadence. On weekends (Sat / Sun US Pacific), no inbound 850 / 860 traffic is normal; the dial reads 36 to 60 hours from Friday evening to Monday morning and is not alarming. The alert logic excludes weekend hours from the threshold count. |
| Cancellations / pauses | Scheduled pause windows (Costco maintenance, supplier integration deployment) can be annotated at the integration level so the alert does not fire during planned downtime. |
| Currency / value | Not relevant; the card is a time delta. |
| FBA / FBM | Not applicable. |
| Time window | RT (real-time, refreshes on every file event from the SFTP poller). |
| Alert trigger | >36h ago on a working day. Excludes Sat / Sun from the 36-hour window. Triggers on any working-day gap exceeding 36 hours (typically Tuesday morning if no files arrived since Friday evening). |
| Roles | operations |
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.| Day | Last successful inbound timestamp | Card reading | Status | What was happening |
|---|---|---|---|---|
| Monday 09 Mar 26 09:00 | Mon 09 Mar 02:30 | 6.5 hours | green | Normal Mon morning; 850 POs landed overnight |
| Monday 09 Mar 26 18:00 | Mon 09 Mar 17:45 | 0.25 hours | green | Mon evening 850 batch just ingested |
| Tuesday 10 Mar 26 09:00 | Mon 09 Mar 17:45 | 15 hours | green | No overnight files (normal for Tue morning) |
| Tuesday 10 Mar 26 14:00 | Mon 09 Mar 17:45 | 20 hours | green | Mid-day Tue still inside threshold |
| Tuesday 10 Mar 26 23:00 | Mon 09 Mar 17:45 | 29 hours | green | Tue evening, edge of normal |
| Wednesday 11 Mar 26 06:00 | Mon 09 Mar 17:45 | 36 hours | warn | Alert fires; investigate |
| Wednesday 11 Mar 26 09:00 | Mon 09 Mar 17:45 | 39 hours | critical | Page on-call ops |
- 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:| Card | Why pair it with Last Successful Inbound | What the combination tells you |
|---|---|---|
| Last Successful Outbound | The other half of the connection. | Inbound green + outbound red = our 856 ASNs are not landing in Costco; inbound red + outbound green = Costco is not sending us anything; both red = SFTP layer outage. |
| SFTP Connection Failure | The cause if both are red. | Direct evidence of an SFTP-level failure (auth, IP allowlist, network). |
| Missing Overnight Feed | The cause if inbound is red on a working morning. | Specifically detects the “no PO file by 7am” pattern. |
| Daily PO Count | Business-level companion. | Inbound green + PO count zero = Costco-side commercial pause; both green = healthy. |
| Sync Error Count (7d) | Parse failures within ingested files. | Files arriving but failing parse means the dial reads stale even though SFTP is up; both signals together identify the layer. |
Cross-connector: pingdom.uptime_status | Generic uptime monitoring. | If the supplier’s integration host is down, this card and the pingdom card both alarm together. |
Cross-connector: vortex_iq.integration_health_summary | Aggregated integration health. | Card is the per-Costco-SIP detail behind the summary. |
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:| Reason | Direction | Why |
|---|---|---|
| SFTP delivery vs ingest | Ours sometimes higher | Costco’s portal records “we dropped this file at timestamp X”; the card records “we successfully parsed this file at timestamp Y”. Y is typically X plus 1 to 30 minutes (SFTP poll cadence + parse time). |
| Parse rejections | Ours higher | A file Costco dropped that the supplier’s integration could not parse (schema error, encoding issue, malformed envelope) is “delivered” in Costco’s view but does not advance this card. Pair with Sync Error Count (7d). |
| Timezone (PT vs UTC) | Display only | Costco’s portal shows Pacific Time; the card stores UTC. Underlying timestamps reconcile. |
| File-type filtering | Either | Some portal views show only 850 / 860 / 820; the card uses any successful parse. A 997 ACK file advances the card without showing in a business-only portal view. |
| Pause windows | Card may differ | If the integration is paused (planned maintenance) the card may not advance even if files were delivered; un-pause to clear. |
| Card | Expected relationship | Causes of legitimate divergence |
|---|---|---|
pingdom.uptime_status | Both fail together if the integration host is down. | Pingdom monitors host-level uptime; this card monitors application-level liveness. Host can be up while application is hung. |
vortex_iq.integration_health_summary | Summary should always include this card’s value. | If summary green and card red, summary refresh is stale. |
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.