Modal 1.6.1 endpoint logs and stats: debug a Sume webhook receiver

When a Sume webhook to your Modal endpoint fails, start with the new modal endpoint logs command from Modal 1.6.1 (2026-10-03), then compare what it shows with the Sume delivery status. The same release adds modal endpoint info and modal endpoint stats. They let you see requests that your function logs would not show, such as a 401 from your own verifier.

What Modal shipped

The Modal changelog lists 1.6.1 on 2026-10-03 with the three modal endpoint subcommands and a container_total_count field. It also says Server.sessions.start() waits up to 25 minutes. Version 1.6.0 (2026-09-28) added @modal.clustered(), @modal.sessioned(), runtime="vm" and max_concurrency.

Match Modal logs to Sume delivery status

Sume sends each attempt with a 10 second timeout, so a cold container that takes longer fails the attempt even if your code is right. Sume retries up to 10 times with 30 seconds between attempts.

A delivery row ends as delivered, retrying, failed or exhausted. If it says exhausted, call POST /v1/jobs/{job_id}/webhook/redeliver; that does not use one of the 10 automatic attempts.

A triage order

Work from the cheapest check outward.

• Run modal endpoint logs for the time of the attempt and look for your own 401 or 500.
• Compare x-sume-webhook-secret-fingerprint on the delivery with the fingerprint in the dashboard; it identifies the secret without revealing it.
• If a rotation is under way, the signature header holds two entries, newest first; a verifier that compares for equality fails during the 24 hour window.
• Check the cold start against the 10 second per attempt limit, and return a 2xx after you store the event, not after you process it.

A receiver that fails closed

Keep the secret in a Modal Secret named SUME_COM_WEBHOOK_SIGNING_SECRET. A missing secret should return 500, not accept the body. The verifier itself is the same one you would use anywhere; the FastAPI rotation post has a Python version.

Cold starts and the 10 second attempt

A web function that scaled to zero has to start a container before it can answer. If that start takes longer than Sume allows for one attempt, the attempt fails and the next one comes 30 seconds later, which is usually warm. The result is a delivery that looks flaky: one failure, then success. modal endpoint stats and the new container count field help you see whether containers are starting for each delivery.

If cold starts are the cause, keep one container warm for the receiver, or make the receiver a thin function that stores the event and returns, and run the heavy work elsewhere.

A Modal web function has a 150 second HTTP timeout, after which the client gets a 303 redirect. Sume does not follow your processing, only your response, so this limit matters only if you do the work inside the request. Return the 2xx first, then process. For any Sume call that you make from Modal, use mode: "async" or a webhook so that you never wait inside that limit.