When a third-party service goes down, it usually doesn’t take Zanda down with it. Most of the platform keeps running, and a lot of the recovery, retries, monitoring, alerts, happens automatically without you needing to do anything. This article explains what keeps working when an external service has a problem, what needs a manual check, and how Zanda vets and reviews every provider it relies on, before and after adoption.
Infrastructure resilience and what an outage actually affects
Amazon Web Services (AWS) is the only external service essential to the core operation of Zanda, since it hosts the underlying infrastructure, and that infrastructure is distributed across multiple data centres per region specifically to avoid a single point of failure. Every other external service or integration supports an individual feature rather than the platform as a whole, so an outage in one of them affects that feature, not access to Zanda generally.
Connection and integration errors are recorded and monitored through the same logging system used internally, triggering automatic alerts so the team can start investigating right away. Dedicated support engineers are available 24/7. If reporting an issue, including the action being performed, the error message, and a screenshot (if comfortable sharing one) helps the team investigate faster - chat is the fastest way to reach support.
Staying informed during an outage
Known issues and regular updates are published on the Zanda System Status Page, and the HelperBee support chat tool also reflects current issue information. Checking the status page and reaching out to support are the two best ways to find out what’s going on.
Where a customer action is genuinely needed to recover from an outage, Zanda aims to minimize that need and to say so clearly - keeping a record of what was being done when the outage occurred makes it straightforward to reattempt or reprocess once the service recovers.
Email, SMS, and other queued work
Emails, SMS, and some other messaging activity queue automatically and retry rather than failing outright, though exactly how long an item stays queued and how it retries varies - typically up to about a day. A message in this state shows as failed or as retrying, rather than leaving a customer guessing, and the queue is monitored separately so completion can be verified once the provider recovers.
Automatic retries carry a small chance of a message going out twice, and manually resending one carries the same risk - Zanda has measures in place to reduce this, but it isn’t eliminated entirely. If a queued message is time-sensitive, it’s worth reaching the client through an alternate method rather than relying on the retry alone.
Payments and claims
Payment transactions are not queued or automatically retried. If a payment provider is unavailable, Zanda notifies promptly rather than leaving it unclear, and the practice should wait a minute or two before retrying the transaction - Zanda does not retry it on the practice’s behalf. Whatever payment result is shown in Zanda can be relied on as accurate.
Insurance claims also aren’t queued or automatically retried. A practice can check a claim’s status directly in Zanda, and support can help confirm a specific status where the available information allows it.
How providers are vetted and reviewed
Before Zanda adopts a new provider, it goes through an extensive formal review covering reliability, security certifications, privacy practices, data location, incident response, business continuity, subcontractors, and any downstream services that provider relies on. That review is approved by the Information Security and Privacy team and forms part of the ISO 27001 information security management system Zanda is audited against.
What gets shared with a third party is reviewed by both the engineering team and the Data Security and Privacy team, kept to the minimum information required, and backed by contractual controls covering security, confidentiality, breach notification, and data handling.
Existing providers are reviewed again every year, and sooner if a security incident, a service outage, a major product change, or a change in that provider’s own privacy practices calls for it. If a provider no longer meets the required standard, Zanda looks for an alternative.
Checking which providers Zanda uses
Zanda publishes a Vendor List of the external providers and services it uses, most of which are the same across regions. Contact Zanda Support if it isn’t clear which listed provider relates to a particular feature.
Frequently Asked Questions
How can I tell if a problem is a third-party outage and not something else?
Check the Zanda System Status Page first, since known issues are posted there in real time. If nothing’s listed and something still feels off, contact support so they can look into it directly.
Will an outage stop me from seeing my calendar or client records?
Only if AWS itself has a problem, since it’s the only service essential to Zanda’s core operation. Every other integration issue is scoped to the one feature it powers, so your calendar and client records keep working normally.