Your Webhook Returned 200. Did the Work Happen?

A webhook can acknowledge a request before its downstream work finishes.

The WHOOP integration behind this site returns HTTP 200 with {"status":"accepted"}. That response can precede the Redis capture and the Google Sheets write. Watching its success rate tells you something useful about incoming requests, but it cannot tell you whether the recovery data reached the sheet.

This is a concrete version of the quiet-failure problem: several different observations can look like “it worked.”

Follow one event

WHOOP’s documentation describes webhooks as notifications of changes; the application fetches the data separately. It recommends a quick successful response, documents delivery retries and warns that webhooks should not be the application’s sole source of truth.

For a recognised recovery or sleep update, the current handler schedules two pieces of work through Next.js after(): diagnostic capture and a refresh of recent WHOOP data into Sheets. It then returns the acceptance response.

Rendering diagram...

The solid path ends at acknowledgement. Dashed paths are deferred attempts; either can fail after the response.

Those stages answer different questions:

A stored event does not imply that the refresh ran successfully. The capture path catches Redis errors, and its streams are bounded. Raw request bodies expire after seven days. It is diagnostic storage; there is no automatic replay worker turning those records into a durable processing queue.

There is an even sharper branch. A signed request containing valid JSON that fails the expected event schema is deliberately acknowledged with 200 and scheduled for diagnostic capture, without forwarding. The code avoids asking WHOOP to keep retrying that payload. Here, success does not even mean an actionable update was recognised.

The sheet can still be stale

Consider this hypothetical execution of the valid-event path: a sleep update is acknowledged, capture succeeds, but Sheets is unavailable. Forwarding logs the failure. The HTTP response cannot subsequently change, and the provider has already received a successful acknowledgement.

That does not mean the response should wait on a spreadsheet write. Fast acknowledgement is reasonable. I would keep it fast and require separate evidence that the downstream state caught up.

HTTP itself is not confused here. RFC 9110 defines 200 as a successful request; this endpoint’s contract is acceptance. Changing the number to 202 would describe deferred processing more explicitly, but it would not supply persistence, retries or completion evidence.

Repair has a window

The repository configures a daily WHOOP reconciliation. Its default lookback is 72 hours: fetch cycles, recovery and sleep again, join them, then append or update each cycle’s row.

That is a second opportunity to recover recent state when the necessary services work. It does not prove a cron ran in production, recover every historical gap or handle every deletion. The current webhook path leaves deleted records’ rows in place.

The reconciliation response also deserves inspection. Individual row failures increment an errors count while processing continues, and the route can return that summary with HTTP 200. Missing configuration can produce a successful HTTP response containing a skipped result. A second green HTTP graph would repeat the first mistake.

For one integration, choose the downstream state you need to be true and trace a failure after acknowledgement. Record when reconciliation last completed, which source records it covered and which writes remain unresolved. Check the summary, not just the response code. Where bounded reconciliation cannot meet the recovery requirement, add a durable handoff before acknowledging.

For the fitness sheet, the useful evidence is that the relevant cycle’s data reached its row recently enough to use. A rising receipt count cannot establish that.