Onboarding stopped completing. The dashboard said fine.

What actually happens

A third party does not have to go down to cost you a day of acquisition. It only has to get slow enough that people give up.

New customer onboarding runs through an identity verification step handled by a third party. On a normal day the step completes in a few seconds and the funnel converts at its usual rate.

The provider does not fail. It starts taking substantially longer to return, and for a subset of document types it starts returning an inconclusive result that puts the application into manual review instead of completing it.

From the platform side everything is healthy. The API call succeeds. The response is a 200. There is no error rate to alarm on, no timeout, no failed dependency. Each individual request looks like a request that worked.

What actually changed is the funnel. People who reach the verification step wait, and a share of them abandon. Those who complete land in a manual review queue that was sized for a much smaller share, so the queue grows and activation slows behind it.

This surfaces eventually through a growth dashboard or a support queue, typically the next morning. The acquisition spend that ran during the stall is already spent, and the applications sitting in manual review have aged past the point where a re-engagement email works well.

Every component was healthy. The system was not. The gap between those two statements is where this class of incident lives.

The same day, two ways

The measure that matters here is not uptime. It is how many people started an application that a healthy-looking system never let them finish.

The cost in the first column is not the outage, because there was no outage. It is eight hours of paid acquisition running into a funnel that could not complete, plus a manual review backlog that has to be worked down afterwards.

The reason this hides so well is that every health check in the chain is asking "did the call succeed". A slow, inconclusive but technically successful response passes every one of them.

Sentinel monitors the funnel step as the object of interest, not the service behind it. Completion rate at each stage is baselined against its own pattern, so a stage that stops converting is a signal even when everything serving it reports healthy.

The replay is the part that recovers real money. Applications that stalled are identifiable, and re-running them through the fallback provider under governance converts a share that would otherwise have aged out. That is a recovery no dashboard-driven investigation can offer, because by the time the dashboard tells you, the list is stale.

Who decides to press go

Switching identity verification providers mid-day changes who is making regulated decisions about your customers, so it is not an action to take automatically.

Reversible steps run under policy: affected applications identified and held, review queue capacity flagged, evidence bundle assembled for the provider conversation.

The ticket is raised and held with the fallback provider MOP, the affected application list, the compliance implications and the rollback path attached. The onboarding owner approves before the switch.

The replay of stalled applications is gated the same way, because re-running a verification is a regulated action and it needs a named approver on the record.

Step completion rate at the verification stage falling against its own baseline for this hour and weekday. All services returning healthy responses.

Provider response times, payload outcomes, document type distribution and manual review queue depth correlated. Provider degraded, inconclusive results concentrated on specific document types.

Action Ticket raised with the fallback provider MOP and affected application list. Held for the onboarding owner. Stalled applications staged for governed replay.

Funnel step completion promoted to a first-class signal alongside service health. Provider added to the degradation watch. Inconclusive-rate threshold added per document type.

This is a platform capability, not a published customer deployment. The mechanism, which is correlated investigation followed by governed MOP execution with pre-check, post-check, rollback and approval gating, is running in production today in our carrier estates; see closed-loop network automation and carrier-scale observability across 27,000+ devices. The payments scenario above is that same mechanism applied to a transaction estate. The timings shown are modelled, not measured at a named payments provider.