Skip to content
Notifications
Clear all

Procurement team here - what specific failure logs should I ask vendors for?

3 Posts
3 Users
0 Reactions
32 Views
(@darrenk)
Honorable Member
Joined: 3 months ago
Posts: 392
Topic starter   [#13462]

Hey everyone! I'm always digging into automation and data flows for my own productivity, so I totally get the need for solid logs when something breaks.

For procurement, you want logs that show the *handshake* between systems. Specifically, ask vendors for:
- API request/response logs for the last failed transaction, with full headers and payloads (masking any sensitive IDs is fine). This catches hallucinated endpoints or bad data formats.
- Webhook delivery attempt logs, including all retries and the exact failure codes. Crucial for payment or approval workflows.
- Any user action audit trail from their platform for the process in question. Timestamps here are key to line up with your own system's logs.

This gives you the actual conversation between tools, not just a generic "error 500" from their dashboard. Hope that helps!

dk


dk


   
Quote
(@infra_ops_learner)
Reputable Member
Joined: 6 months ago
Posts: 297
 

That makes sense, the handshake is what really matters. I'd add network-level logs too, like connection timeouts or TLS errors from their load balancer. Sometimes the API call never even reaches their application logic.

Great point about timestamps. Asking for them in UTC saves a huge headache lining things up.


CloudNewbie


   
ReplyQuote
(@hiroshim)
Noble Member
Joined: 3 months ago
Posts: 767
 

Network logs are indeed critical, but you must specify the layer precisely. Asking for "load balancer logs" is often too vague and yields an unmanageable data dump. Instead, request the connection metrics from their ingress controller or CDN for the specific transaction's client IP and timestamp window.

The key detail often missing is TLS handshake duration. A timeout there points squarely at a misconfigured cipher suite or certificate chain issue on their side, not your application's API call. Also insist on seeing the backend server identifier that received, or dropped, the SYN packet. This isolates whether it's a global load balancer problem or an issue with a specific unhealthy host behind it.

Always correlate these with your own client-side TCP dumps. If their logs show a successful completion but yours show a reset, you've uncovered a middlebox, like a stateful firewall, silently terminating the connection.



   
ReplyQuote