Does NexHealth Send a Webhook When EHR Sync Turns Red?

Do not assume NexHealth sync-status webhooks reliably announce every change from green to red. For read sync, the Webhook Subscriptions reference documents red-to-green recovery and says green-to-red does not trigger the event. For write sync, the page’s prose says recovery-only while its example shows sync_status_write_change.red with write_status set to red. That contradiction needs NexHealth confirmation before a team relies on write-side event direction.

The safer documented monitoring path is to inspect GET /sync_status and evaluate read_status_at and write_status_at. Those timestamps need context because NexHealth warns that activity outside business hours, especially on weekends and holidays, can make them appear several hours or days old. Webhooks and polling therefore provide different evidence.

What do NexHealth sync-status webhooks actually report?

NexHealth lists separate events for read and write functionality. The documented read event fires when an integration’s read status moves from red to green. The page’s prose assigns the same recovery direction to write functionality, but its write example instead uses sync_status_write_change.red and reports write_status as red.

The source explicitly says the read webhook does not currently trigger from green to red. Its write prose makes the same statement, yet the contradictory example prevents a categorical write-side conclusion. Treat read failure notification as absent and write failure notification as undocumented until NexHealth resolves the conflict.

Do not treat either event as a complete uptime feed. A recovery event can confirm a return to service after NexHealth observes the transition, but it cannot prove when the red state began. A possible write-red event does not establish a complete delivery guarantee either. Detect degraded connectivity through an independent status check.

This differs from appointment delivery behavior. The guide to Zocdoc webhook retry boundaries concerns transport acknowledgement for appointment events. A NexHealth sync-status event concerns EHR integration health. Keep those two kinds of monitoring separate.

Why is waiting for a green-to-red event unsafe?

A webhook-only monitor can remain quiet while reads are red because the missing transition is documented behavior. Write-side silence is also ambiguous because the source conflicts about failure events. It can mean the integration stayed healthy, no relevant event occurred, or a failure was not delivered to the listener.

That ambiguity matters for scheduling. If reads are degraded, the application may not have current appointments or unavailability blocks. If writes are degraded, a booking request may not reach the connected record system as expected. Neither condition should be translated into a positive claim merely because no webhook arrived.

Operational inference: use the status query as the failure-detection input and treat webhooks as supplementary transition signals. Confirm write-event direction with NexHealth before making it a control dependency. This is not a polling interval prescribed by NexHealth. Each team must choose a cadence that fits its booking risk, API limits, business hours, and incident process.

If a status problem first appears as an empty availability response, also inspect the scheduling inputs. NexHealth availability can be empty despite an open EHR calendar when working hours or appointment-type assignments do not qualify. Sync health and availability configuration are related evidence, not interchangeable diagnoses.

How should GET /sync_status be monitored?

The sync-status endpoint can be scoped by institution through subdomain. Its documented query options include read status, write status, and location identifiers. That lets a monitor ask about the exact integration scope used by the booking flow instead of reducing every location to one account-wide light.

Track read and write independently. A location can need fresh read state for availability while also needing working write state for appointment creation or changes. One green value should not hide a red value in the other direction. Display both status and the corresponding last-success timestamp.

Store a technical snapshot rather than a patient payload. Institution alias, location scope, observed read state, observed write state, timestamp ages, request result, and monitor time are enough for the health question. Patient names, contact details, appointment reasons, notes, and insurance data add no value to this test.

A status monitor also should distinguish a successful API response from a healthy integration. An HTTP response can carry a red status. Conversely, a failed status request leaves health indeterminate rather than proving the EHR is red or green. Preserve those states separately in alerts.

How do off-hours delays change alerting?

NexHealth warns that read_status_at and write_status_at can show delays of several hours or days outside business hours, particularly on weekends and holidays. An old timestamp alone is not enough to declare an outage without considering whether the connected practice was expected to generate activity.

This warning does not mean stale timestamps should be ignored. It means the monitor needs context. A timestamp that is normal for a closed office may be suspicious during active booking hours. Use the practice’s documented schedule as an operational input, not a vendor-wide threshold invented for every location.

Operational inference: alert on a combination of state, timestamp age, expected activity, and failed business operations. Keep the rule visible to clinic IT so a holiday schedule can be explained without silencing a genuine write failure.

Working hours themselves have a separate role in availability calculation. The article on NexHealth appointment validation outside working hours explains why an accepted API call and a valid booking slot are different claims. Do not reuse clinic hours as proof that sync is healthy.

What should the booking flow do while status is uncertain?

Make uncertainty explicit. If current EHR reads cannot be established, do not convert missing busy records into free time. If write health is red or unknown, do not present a local request as a completed EHR booking. The safest user-facing state is pending, unavailable, or under review, according to the clinic’s approved workflow.

Do not silently switch to a different calendar or operatory. A fallback may have different scope and may create a duplicate appointment. The discussion of overlapping operatories in NexHealth availability shows why resource identity must remain attached to a time.

Separate read controls from write controls. A practice might decide that existing appointments remain viewable from a recent local mirror while new bookings pause. Another practice may require the whole scheduler to close. NexHealth documents the status surfaces, but the acceptable degraded mode belongs to the clinic and its application.

Show operators which capability is affected. “Integration issue” is too broad. “EHR reads are red; online slots paused” or “EHR writes are indeterminate; requests held for review” makes the state actionable without exposing appointment content.

How should recovery be reconciled after red turns green?

A red-to-green read webhook confirms the documented recovery transition. A red-to-green write event is also consistent with the page’s prose, despite its contradictory red example. Neither proves that every operation attempted during degradation reached the EHR or that the local mirror is complete. Treat a recovery signal as a trigger to start reconciliation, not as automatic closure.

Review the bounded interval between the last trusted success and observed recovery. Compare queued or uncertain technical operations with current EHR state through approved identifiers. Do not replay every request blindly. A booking may have succeeded before connectivity became uncertain, and an unconditional replay could create a duplicate.

Operational inference: make reconciliation idempotent and preserve the original booking lineage. A recovered write should not become a new acquisition event or replace the original channel. The distinction in appointment source versus marketing source remains valid during incident recovery.

Close the incident only when current status is known, affected locations are checked, uncertain operations have an outcome, and availability is based on refreshed state. The recovery webhook is one piece of that evidence.

What controlled test proves the monitoring design?

Use a sandbox or approved non-production integration with synthetic records. Test read and write monitoring separately. The goal is not to force a production EHR outage. It is to prove how the application behaves when the status endpoint reports red, when the endpoint itself fails, and when a recovery event arrives.

1. Capture a known green read and write state for one controlled location.
2. Feed the monitor a controlled red read state and verify availability fails closed.
3. Feed it a controlled red write state and verify new writes remain visibly uncertain.
4. Test an unavailable status endpoint and confirm the state becomes indeterminate.
5. Deliver a red-to-green recovery event and verify reconciliation starts.
6. Confirm no test record contains real patient or clinical information.

Also test off-hours context. A delayed success timestamp during a configured closure should follow the documented alert rule, while an explicit red state should remain visible. Record the exact status inputs and resulting control decision so reviewers can reproduce the outcome.

Frequently asked questions

Does NexHealth send a webhook when read status changes from green to red?

No. The current Webhook Subscriptions reference says the read-status webhook fires from red to green and does not currently trigger from green to red. Use the sync-status endpoint to monitor the failure state.

Are read_status_at and write_status_at outage timestamps?

They are last-success timestamps used to assess sync health, but NexHealth warns they can lag outside business hours. Interpret their age with location schedule and current status rather than treating any delay as a confirmed outage.

Does the write-status webhook report a change from green to red?

The current reference is internally inconsistent. Its prose says the write event reports red-to-green recovery and does not trigger green-to-red, while its example shows a red write event. Ask NexHealth to confirm current behavior and monitor GET /sync_status instead of depending on one interpretation.

Should missing EHR reads be treated as open availability?

No. Missing or indeterminate calendar state is not evidence of free time. Pause or qualify availability according to the clinic’s approved degraded-mode policy until current read health and calendar coverage are established.

References

• NexHealth, “Webhook Subscriptions,” reviewed August 16, 2026, https://docs.nexhealth.com/reference/webhook-subscriptions.
• NexHealth, “View sync statuses,” reviewed August 16, 2026, https://docs.nexhealth.com/reference/getsyncstatus.