Zanda listens to how practices actually work, then designs and delivers new features, fixes, and security updates on an ongoing basis. You stay on the latest, most secure version without waiting for occasional big-batch upgrades or the downtime that can come with them. This article covers the controls that keep those releases safe before they go live, how quickly a problem gets fixed if one does slip through, and why routine maintenance rarely takes Zanda offline.
Why releases are small and frequent
The engineering team favors small, frequent updates over large, infrequent ones, releasing daily. A smaller update carries lower risk than a large batch of changes released all at once, so this is a deliberate safety choice, not just a pace of work.
Controls before a release goes live
Every code change is tracked and reviewed by at least one engineer before release. Tens of thousands of automated checks run before that review, covering security, performance, data protection, and simulated customer actions with their expected outcomes - and the engineer who made the change is responsible for those checks passing. Application and database changes go through the same review, testing, and sign-off process. Each piece of work also gets its own separate testing environment, where the quality-assurance and product teams can try the updated version before it goes live. Emergency security fixes can move faster, but they still go through review and sign-off - that step is never skipped.
Gradual rollout and early feedback
Features are designed around how practices really use them, not released mechanically and left as-is, and that shows up in how a rollout happens. New features often reach a small beta group first - customers who asked for the feature, plus volunteers, invited or opted in, who can drop out of the beta at any time on request. Feature flags control that limited rollout, and before a feature goes wider, its performance, system logs, and the beta group’s feedback are all reviewed. From there, a feature can roll out gradually to more regions or customer groups rather than everyone at once. Release notes for new features, changes, and improvements are published in-app - see Using Practice Hive for Notifications, Release Notes, and Team Chat for where to find them.
If a release causes a problem
A malfunctioning feature can be switched off immediately using its feature flag, and any data already created through it is preserved rather than lost - it only comes back after being fixed and re-tested, with a target of resolving the issue within hours. If a fix needs a full rollback instead, that’s available without downtime and normally takes about 15 minutes, regardless of region or release type; it doesn’t interrupt service, lose data, or need any action from customers. Database rollbacks specifically are designed to retain data and avoid corruption. Regions are independent here too - a release can be rolled back in one region without touching the others.
Maintenance and planned downtime
Routine maintenance happens daily and normally doesn’t require Zanda to be unavailable: most software releases and minor database updates go live with no downtime or service impact at all. A major database-version update can occasionally need a few minutes of planned downtime, scheduled after hours with about a week’s notice, and the status page shows the timing in each customer’s own time zone. See Reliability and Availability for how planned maintenance factors into the published uptime figure.
How customers are kept informed
Planned maintenance is communicated by email and on the status page, covering the timing, what’s affected, progress, and completion. An unexpected issue is instead raised through the ticketing system, and potentially chat. Customers can subscribe to the status page to get an email whenever it changes - see Zanda System Status Page for how. If an update affects a third-party integration a practice uses, affected customers get a proactive email about it.
Frequently Asked Questions
How can Zanda release updates this often without putting my data or access at risk?
Through the controls in place before anything goes live - mandatory code review, tens of thousands of automated checks, a dedicated test environment per change, and QA sign-off - plus gradual rollout via feature flags so a new feature reaches a small group before everyone.
If a release causes a problem, how quickly can it be undone?
A malfunctioning feature can be switched off immediately via its feature flag, with data preserved. A full rollback, if needed, normally takes about 15 minutes, doesn’t cause downtime or data loss, and doesn’t need any action on a customer’s part.
Does routine maintenance normally take Zanda offline?
No. Routine maintenance and most updates go live with no downtime at all. The exception is an occasional major database-version update, which can need a few minutes of planned downtime, scheduled after hours with about a week’s notice.
How will I know about planned maintenance or an unexpected issue?
Planned maintenance is communicated by email and the status page ahead of time. An unexpected issue is raised through the ticketing system, and potentially chat. Subscribing to the status page gets you an email whenever it updates.