Pre-bid Troubleshooting

If something looks wrong, reach out to your Pinokio account manager — we are happy to dig in. The information below covers the most common categories of issue and the questions we will likely ask first. Coming to the conversation with answers speeds up the process.

Latency

Pre-bid is designed to answer in well under a millisecond on a co-located host. If you are seeing higher numbers, the cause is almost always one of four things: the binary is far away, connections are being recycled too often, the process is under-resourced, or something between the bidder and the binary is adding overhead.

Useful answers to bring:

• Where is the binary running relative to the bidder? Same host, same rack, same VPC, or different Availability Zone?
• Is anything routing the request through a proxy, sidecar container, or service mesh?
• Are you using persistent HTTP/1.1 connections with keep-alive, or opening a new connection per lookup?
• What is the host’s CPU and memory utilization during peak QPS?
• Did latency change after a recent deploy, kernel update, or network change?

Connectivity

If the bidder cannot reach the binary at all, work backwards from the network:

• curl http://localhost:<port>/health-check from the bidder host. A 200 means the binary is reachable; a 503 means the binary is up but unhealthy; anything else (connection refused, timeout) means the process is not listening or the port is blocked.
• Check that the binary process is actually running and bound to the expected port.
• Check for firewall, iptables, or container-network rules that might be dropping traffic between the bidder process and the binary.

Connection management

Poor connection management is the single most common source of avoidable latency. Each new TCP/HTTP connection costs time the binary cannot make up for. Aim for a small pool of long-lived connections shared across bidder workers.

If you are seeing latency spikes that correlate with traffic ramps, your connection pool is probably too small or being closed too aggressively. Tune the keep-alive window upward and reduce churn.

Test at realistic QPS — low-volume tests will not show connection-management problems. Run validation traffic above 200 QPS to get representative numbers. Pre-bid is designed to handle even extreme cases of around 100k QPS per instance.

Health and process

The /health-check endpoint returns 200 if the binary is healthy and 503 if it cannot serve lookups. If you are receiving 503:

1. Check the binary’s local logs. Configuration issues and startup failures show up there first.
2. Confirm the API key is set correctly.
3. Restart the process and see if the condition clears.
4. If 503 persists, contact your account manager with the log output.

Scoring concerns

If you suspect predictions are off — too many high-risk bands, too few, or unexpected schain failures — that is generally a Post-bid question. Post-bid analysis is what tells us whether Pre-bid’s predictions match reality. If you are not running Post-bid yet, that is the first thing to enable. See the Post-bid overview.

When you do escalate a prediction concern, send us:

• a recent representative request body (you can redact identifiers)
• the response payload returned by the binary
• a sample size and time window for the traffic in question
• which dimensions (p1–p5, geo, publisher) the concern is grouped by

Information to include in a support request

A good support request includes:

• Were there any recent changes to your bidder, network, or deployment topology?
• Were there any recent traffic-volume changes (expected or unexpected)?
• Has the issue persisted for at least 30 minutes, or was it a short spike?
• Are you running on the same host as the bidder? If not, what is the network path?
• A latency histogram broken out by instance, if you have one — for example: 50% under 1ms, 30% 1–2ms, 15% 2–5ms, 5% above 5ms.
• Any binary logs covering the affected window.