Reliability
Contracts move on deadlines. Harmonity is operated with monitoring, backup, and incident processes designed to support business-critical contract workflows—so teams can keep work moving from draft to approval to renewal.
This page is a high-level operational overview. Specific uptime commitments and service credits (if any) are defined in our Service Level Agreement (SLA).
1. Availability approach
We design and run Harmonity to be available and resilient under normal operating conditions, using:
- Redundancy for critical components where feasible
- Controlled deployments and change management practices
- Continuous monitoring and alerting
- Backup and recovery routines
What counts as “unavailable”
Generally, “unavailable” means the Service cannot be accessed or core functionality cannot be used due to an issue within Harmonity’s responsibility.
What is typically excluded
- ●Scheduled maintenance communicated in advance (where feasible)
- ●Issues caused by Customer environment (e.g., device, network, browser, SSO/IdP outage)
- ●Third-party outages outside Harmonity’s reasonable control (e.g., public internet, major cloud provider regional incidents)
For formal definitions, measurement methodology, and any service credits, see the SLA.
2. Monitoring & operational alerting
We use monitoring and alerting to detect and respond to operational issues, including:
- Service health checks and error rate monitoring
- Performance monitoring (latency and throughput signals)
- Availability signals (endpoint reachability and key workflow checks)
- Operational escalation to on-call responders when thresholds are exceeded
Where appropriate, we maintain logs to support troubleshooting, incident investigation, and reliability improvements.
3. Backups & recovery (high level)
We operate backups and recovery routines designed to support:
- Restoration of data in the event of accidental deletion or system failure
- Recovery from service-impacting incidents
Key principles
- Backups are protected with access controls and security practices consistent with our Trust Center
- Recovery procedures are tested and improved over time (risk-based)
If you require specific RPO/RTO commitments, please request our security package or discuss enterprise requirements with sales.
4. Planned maintenance & changes
We may perform maintenance, upgrades, and releases to improve security, performance, and functionality.
Our approach
- We aim to schedule maintenance during low-usage hours when feasible
- We aim to provide advance notice for changes that are reasonably expected to materially impact availability
- Emergency maintenance may be required for security or stability reasons
Maintenance communications
5. Incident response & customer communications
We run an incident process to restore service as quickly as possible and learn from outages.
Typical incident lifecycle
How we communicate
- ●For significant service-impacting incidents, we aim to provide timely updates through available channels (and later via a status page).
- ●Post-incident summaries may be shared for major incidents where appropriate and permitted.
6. Support hours & response expectations
Reliability response and support obligations may depend on your plan (e.g., standard support vs. premium support coverage).
Plan-specific response targets, severity definitions, and measurement windows are defined in the SLA (and/or Order Form, if applicable).
Include: workspace name, impacted users, timeframe, screenshots (if available), and steps to reproduce.
7. SLA and service credits
If your subscription includes an SLA with uptime targets and service credits, those terms are governed solely by the Service Level Agreement (and your Order Form, if applicable). This page does not modify the SLA.
Related links
8. Change log
| Date | Change |
|---|---|
| February 1, 2026 | Initial publication |