Executive Summary: No received webhook is not evidence that a monitored business stayed unchanged. Cobalt documents a result envelope for every monitoring check, while its monitored-business listing exposes scheduling and progress fields.[1] Reconcile those fields with the events your application actually retained before treating silence as a completed review.
What can silence mean in a monitoring workflow?
Your application knows only that it has not retained the expected event. It does not yet know whether the provider performed the check, whether delivery is pending, whether the receiver failed, or whether the monitor remains active.
Start with that limited observation. An operations dashboard should say “Expected check not reconciled” rather than “No changes” until the evidence supports the stronger statement.
Does Cobalt send only change alerts?
The current enrollment documentation describes every check using the same response envelope, including the baseline, later changes and a completed not-found check.[2] That is why silence should not be interpreted as the equivalent of a delivered no-change result.
A retained event with hasChanges=false is still an event that must be interpreted in context. The same envelope also identifies isBaseline, found, checkNumber and checkedAt.[3] Those fields distinguish outcomes that a single alert count would hide.
What does the lender need to know?
For a portfolio review, the useful question is whether the expected source observation occurred and reached the evidence history used by the team. That question precedes any assessment of what the business record says.
A monitoring service can support the workflow with source observations. Your application still needs to know whether it received and processed them before presenting a current portfolio status.
Which fields help reconcile the expected check?
Cobalt's monitored-business list includes masterRequestId, nextCheckDate, lastChecked, checkCount and checkInFlight.[4] Keep the returned snapshot and the time you retrieved it, then compare it with your local event history for the same monitor.
Treat these as evidence about different aspects of progress, not interchangeable proof of completion. An in-flight flag, a last-checked timestamp and a local receipt record each answer a different question.
What should you compare first?
Confirm that the monitor identity in your application matches the listed masterRequestId. Then inspect the expected scheduling information, the latest reported check information and the events actually stored locally.
Do not join by business name alone. Two names can be similar, and a lender can have more than one internal review associated with the same business. Preserve the provider monitor reference and your own application or portfolio context.
Is nextCheckDate an exact delivery deadline?
Do not assume that. The current list example represents it as a date.[5] Confirm scheduling and timezone semantics before converting that value into a precise delivery deadline in your operations system.
Your own grace period should be explicitly defined as a local policy. It is not a Cobalt completion guarantee or a promise that a filing office will update at a particular minute.
How should the reconciliation classify an unresolved check?
Use a few states that direct the next investigation. Avoid making every discrepancy a borrower-risk alert; first establish whether the issue concerns source progress, event delivery or local processing.
A practical classification includes:
• Provider check time. Preserve checkedAt from the monitoring callback separately from the local receipt time.[6]
• Not yet due under local policy. The expected observation has not crossed the team's defined review threshold.
• Reported in flight. The listing indicates a check in progress; retain that observation and follow the supported escalation path if needed.
• Provider progress observed, local evidence missing. Check information advanced, but the corresponding evidence has not been reconciled locally.
• No recent provider progress established. The expected check is unresolved and the listing does not establish a newer completed observation.
• Monitor identity or enrollment needs review. The expected monitor cannot be reconciled with the current listing.
• Evidence received and reviewed. The relevant delivered event is retained and interpreted within its actual source scope.
The list endpoint documents the progress fields used for this investigation, but it does not document an automatic remediation action for every discrepancy.[7] These categories are proposed customer-side operating states.
Can checkCount prove which event is missing?
Use count changes as a reconciliation signal, not a substitute for event identity. Confirm the relationship between provider counters and event numbering in the actual contract before deriving a missing-event range automatically.
A counter cannot show whether your receiver retained the full payload, whether downstream processing succeeded or whether an analyst saw the result. Inspect the local evidence history as well.
What should the reconciliation process store?
Retain the provider-list snapshot, retrieval time, local latest-event reference and the resulting disposition. This gives operations a way to explain the alert without reproducing the exact timing of the original incident.
The following is illustrative customer-side logic using a normalized view. It does not define Cobalt scheduling semantics or a native recovery endpoint.
def reconcile_monitor(expected_due, grace_elapsed, provider, local):
if not expected_due or not grace_elapsed:
return "within_local_wait_policy"
if provider is None:
return "monitor_identity_review"
if provider["check_in_flight"]:
return "source_progress_review"
if provider["newer_check_observed"] and not local["evidence_reconciled"]:
return "delivery_or_processing_review"
if not local["evidence_reconciled"]:
return "expected_check_unresolved"
return "check_reconciled"What should newer_check_observed mean?
Define it from the actual provider evidence and confirmed field semantics. Do not set it from the current clock or from the mere existence of a listing row. Preserve the specific timestamp or counter observation that caused the application to classify progress.
How should a resolved alert close?
Attach the event or source evidence that resolved the discrepancy and identify whether the cause was delivery, processing, scheduling interpretation or another confirmed issue. Do not close an alert simply because a later unrelated check arrived.
Our guide to storing monitoring webhook history covers the evidence store itself. This article adds the separate check that expected observations are accounted for.
How should the team investigate a delivery gap?
Start with the receiver and its retained event records. Confirm whether the relevant payload reached the endpoint, whether it was accepted, whether it was stored and whether downstream processing completed. Those are distinct stages in your application.
Cobalt's current webhook guidance calls for a publicly reachable HTTPS receiver, a prompt 2xx response and duplicate handling using masterRequestId plus checkNumber; it also describes retrying failed delivery with backoff.[8] Use that contract when diagnosing the receiver, without assuming unlimited retries or a particular recovery deadline.
What if the receiver acknowledged before storing the event?
Investigate the gap in your own processing path. A successful HTTP acknowledgment and durable evidence storage are not the same application operation. Choose and test a receiver design that makes the meaning of acknowledgment clear.
If the event is missing, confirm the available recovery route with the provider. Do not invent a history-download or redelivery endpoint merely because it would be convenient. Record the unresolved evidence requirement until a supported route resolves it.
What if the event was stored but not shown to operations?
Trace the local processing and display path. Preserve the original payload, processing status and error information needed to diagnose the problem. The business record itself may not be the issue.
Middesk's webhook documentation also describes event-driven handling for business changes.[9] That is category context for separating event receipt from application behavior, not proof that different providers share the same retry or delivery rules.
What if the delivered result says no change or not found?
Once an event is obtained, interpret its actual fields. Cobalt's baseline example has no changes, and its documented not-found example also has hasChanges=false with found=false and an empty result set.[10]
That means “no changes” alone is not enough to describe the business evidence. Preserve the baseline and found state alongside the change indicator.
Does a not-found check mean the monitor failed?
Cobalt explicitly describes a not-found result as a real delivered check and says monitoring continues on the configured cadence until stopped.[11] It should therefore be distinct from no event received.
The underlying business question may still need review. Do not infer dissolution, closure or misconduct solely from a not-found response. Record what the check returned and route the identity or source question appropriately.
Can a reconciled check close every portfolio concern?
No. Reconciliation establishes that the expected observation was accounted for. The content of that observation and its effect on a lending decision are separate matters.
The point-in-time verification and monitoring comparison provides broader context for those different purposes. Keep the monitoring health question separate from the borrower's credit review.
First establish that the expected check is accounted for. Then interpret what it says about the business record.
What does an overdue-check investigation look like?
Consider an illustrative portfolio monitor that your local policy expects to have produced another observation. Your application has no corresponding retained event. These facts are invented to demonstrate the investigation.
Operations retrieves the current monitor listing and finds reported check progress newer than the last local evidence. The task is classified as a delivery-or-processing investigation. The team traces the receiver and discovers whether the event was never received, failed storage, or was retained but not processed.
What if the listing shows an in-flight check instead?
Keep the evidence state open and follow the team's source-progress review policy. Record the listing snapshot and next investigation time. Do not repeatedly reenroll the same business as an improvised retry, because that can create a different monitor rather than resolve the existing one.
What if the monitor is absent from the listing?
Investigate identity and lifecycle context. The list endpoint is documented as returning businesses currently under monitoring.[12] Check the expected monitor reference and authorized enrollment or stop history before assigning a cause.
An absent listing does not, by itself, establish that the business disappeared from the registry. Keep the service configuration question separate from the source-business question.
What should you test and confirm before rollout?
Build synthetic cases for a check not yet due, a reported in-flight check, provider progress without local evidence, a locally stored event that failed downstream processing, an unknown monitor reference, a delivered no-change result and a delivered not-found result.
What should the acceptance test prove?
The dashboard must distinguish these cases and assign a useful next action. A test should fail if silence becomes “no change,” if a not-found event becomes “no check,” or if a local processing error is presented as a change in the borrower's business status.
Test the chosen scheduling interpretation too. Include date boundaries and the team's grace period so a display timezone does not create premature overdue alerts. Treat the thresholds as documented local settings rather than hidden constants.
What should a Cobalt evaluation demonstrate?
Ask to inspect the monitor listing and delivered envelopes together. Confirm field meanings, correlation, retry behavior and the supported path for unresolved evidence. Cobalt documents these as separate listing and enrollment/webhook surfaces.[13]
Bring your expected-check scenario to a Cobalt demo. The practical outcome is a portfolio view that can tell the difference between a completed check with no reported change and a check whose evidence has not yet been accounted for.
.jpg){kind=small}
.png)