Service Reliability and Availability Policy
Last updated: August 22, 2021
This policy describes the general expectations that apply to uptime, maintenance, operational continuity, and service availability for services operated by Anthony Kung ("we", "us", or "our"). It is intended to help users understand the baseline operational posture of the Services, particularly where a product is provided without a bespoke enterprise support agreement.
Reliability expectations vary by product type. Some Services may be customer-facing production systems, while others may be internal tools, research systems, personal projects, or experimental features under active development. Because of that variation, this policy is written as a general baseline rather than a guarantee for every product or deployment scenario.
Related documents: Terms of Service, API Usage Policy, and Security Disclosure Policy.
1. General Nature of the Services
The Services may include production applications, prototypes, beta products, APIs, automation tools, developer utilities, and experimental software. The operational maturity of a Service may depend on its stage of development, the level of usage, and whether it is offered under a custom commercial arrangement.
Unless expressly stated otherwise in a separate written agreement, you should assume that a Service is offered on a commercially reasonable efforts basis rather than under a formal managed-service commitment.
2. No General Service Level Agreement
Unless we expressly agree otherwise in writing, the Services are not provided with a guaranteed uptime percentage, service credit regime, recovery time objective, or recovery point objective. This means that interruptions, performance degradation, maintenance windows, or unplanned outages may occur without giving rise to contractual service credits or other remedies.
Where a Service is supported by third-party infrastructure, those providers may also impose their own limits, maintenance windows, incidents, and regional constraints that affect overall availability.
3. Maintenance, Releases, and Operational Changes
We may perform scheduled or unscheduled maintenance, deploy code changes, change vendors, rotate credentials, reconfigure infrastructure, or temporarily disable functionality in order to preserve security, improve performance, respond to incidents, or evolve the product.
When practical, we may try to schedule disruptive work in a manner intended to reduce impact. However, emergency maintenance and security-driven actions may need to be performed without advance notice.
4. Third-Party Dependencies
Availability and performance may depend on factors outside our direct control, including cloud hosting, DNS, networking, payment processors, AI vendors, storage providers, authentication systems, and software dependencies.
Failures or degradation in those systems may affect the Services even where our own application logic is functioning as intended.
5. Experimental and Preview Features
Some features may be identified as beta, preview, experimental, research, or early-access functionality. These features may be incomplete, unstable, or materially different from generally available products. They may be changed, suspended, or removed without notice.
You should not rely on experimental features for critical workloads unless you have independently evaluated the associated risk.
6. Data Durability and Customer Responsibility
Unless a specific Service expressly states otherwise, you should not treat the Services as your sole system of record, backup, or archival system. You are responsible for maintaining your own backups, export processes, and business continuity plans where those matters are important to you.
Operational failures can occur for many reasons, including software defects, operator error, dependency outages, malicious activity, and infrastructure failures. While we take reasonable steps to reduce those risks, we do not guarantee that data will never be lost, delayed, corrupted, or made temporarily inaccessible.
7. Incident Handling
When a significant service issue occurs, we may investigate, mitigate, repair, roll back, disable affected features, or otherwise respond in a manner we believe is appropriate under the circumstances. Prioritization may depend on severity, blast radius, security implications, available staffing, and technical constraints.
We do not guarantee any particular response time, restoration time, public communication cadence, or post-incident reporting format unless separately agreed in writing.
8. Changes to This Policy
We may revise this policy as products, infrastructure, and operating practices evolve.
9. Contact
Questions about service operations or availability may be sent to support@anth.dev.
