Service Availability / Status

Asiyst is designed to provide reliable access to its Services, including its web applications, APIs, SDKs, CLI tools, AI assistants, avatars, integrations, and related infrastructure.

This policy explains:

• Service availability.
• Service status information.
• Maintenance.
• Service interruptions.
• Third-party dependencies.
• Incident communication.
• Recovery procedures.
• Customer responsibilities.
• Availability limitations.

This policy may apply to the following Asiyst Services:

• Asiyst website.
• Web application.
• Dashboard.
• APIs.
• SDKs.
• CLI.
• AI assistants.
• Avatars.
• Knowledge-source functionality.
• Authentication.
• Project and workspace functionality.
• Integrations.
• Billing-related functionality.
• Other production services operated by Asiyst.

Availability may differ between individual Services.

Asiyst aims to maintain reliable availability of its production Services.

Availability may be affected by:

• Scheduled maintenance.
• Emergency maintenance.
• Infrastructure failures.
• Software failures.
• Network failures.
• Security incidents.
• Third-party provider outages.
• AI provider outages.
• Payment provider outages.
• Internet connectivity.
• Events outside Asiyst's reasonable control.

Unless a separate written agreement expressly provides otherwise, Asiyst does not guarantee uninterrupted or error-free availability of every Service at all times.

Temporary interruptions may occur as part of normal operation, maintenance, upgrades, or unexpected incidents.

Asiyst may provide service-status information through a designated status page or other communication channel.

Status information may describe:

• Operational status.
• Partial degradation.
• Service interruptions.
• Maintenance.
• Incidents.
• Recovery progress.

A status system may use categories such as:

• Operational.
• Degraded performance.
• Partial outage.
• Major outage.
• Maintenance.
• Investigating.
• Identified.
• Monitoring.
• Resolved.

The exact status terminology may vary depending on the status system used by Asiyst.

A Service may be marked operational when Asiyst has no known material issue affecting normal operation of that Service.

An operational status does not guarantee that every user, geographic location, integration, or request will operate without an error.

A Service may be classified as degraded when the Service remains available but experiences reduced performance or functionality.

Examples may include:

• Increased response times.
• Elevated error rates.
• Delayed processing.
• Intermittent failures.
• Reduced functionality.

A partial outage may occur when a material portion of a Service is unavailable while other functionality remains operational.

For example, API functionality may remain available while a particular dashboard feature is temporarily unavailable.

A major outage may occur when a significant portion of a critical production Service becomes unavailable.

The scope and classification of an outage may depend on:

• Number of affected users.
• Affected functionality.
• Duration.
• Severity.
• Business impact.

Asiyst may perform maintenance to:

• Deploy software updates.
• Apply security fixes.
• Upgrade infrastructure.
• Improve performance.
• Modify databases.
• Update dependencies.
• Improve reliability.
• Implement new functionality.

Maintenance may temporarily affect availability.

Where reasonably practical, Asiyst may provide advance notice of scheduled maintenance that is expected to materially affect Service availability.

Notice may be provided through:

• Status pages.
• Email.
• In-product notifications.
• Other appropriate communication channels.

Not all maintenance requires advance notice.

Asiyst may perform emergency maintenance without advance notice when necessary to:

• Protect security.
• Prevent data loss.
• Address critical vulnerabilities.
• Restore service.
• Prevent further disruption.
• Respond to infrastructure failures.

Emergency maintenance may result in temporary service interruption.

Where maintenance windows are announced, the stated time represents an expected maintenance period rather than a guarantee that all Services will be unavailable or restored within that exact period.

Maintenance may finish earlier or continue longer when necessary.

A service incident may involve:

• Service unavailability.
• Elevated error rates.
• Significant performance degradation.
• Processing delays.
• Authentication problems.
• API failures.
• Integration failures.
• Other material operational issues.

Asiyst may use:

• Automated monitoring.
• System alerts.
• Error reporting.
• Performance monitoring.
• Security monitoring.
• Customer reports.
• Internal operational review.

Not every incident is detected immediately.

When a material issue is identified, Asiyst may investigate:

• The affected systems.
• The nature of the issue.
• The potential impact.
• The cause.
• Available mitigation measures.
• Recovery options.

Investigation may continue after Service functionality has been restored.

When appropriate, Asiyst may provide status updates during significant incidents.

Updates may include:

• Confirmation of an incident.
• Affected Services.
• Current status.
• Mitigation efforts.
• Expected next update.
• Resolution information.

Information may be limited while an incident is under investigation.

An incident may be considered resolved when Asiyst determines that the affected Service has returned to normal or acceptable operation.

Post-resolution investigation may continue after the status is marked resolved.

For certain significant incidents, Asiyst may conduct a post-incident review.

The review may consider:

• Root cause.
• Contributing factors.
• Duration.
• Impact.
• Detection.
• Response.
• Recovery.
• Preventive measures.

Asiyst may provide a summary where appropriate.

Customer notifications may be provided when:

• A significant incident affects customer use.
• Contractual notification is required.
• Applicable law requires notification.
• Asiyst determines notification is appropriate.

Notification methods may include:

• Email.
• Status page.
• Dashboard notification.
• Other available communication channels.

A status page is intended to provide operational information but may not reflect every issue immediately.

There may be a delay between the occurrence of an incident and its appearance on the status page.

Asiyst may depend on third-party providers for critical functionality.

Third-party dependencies may include:

• Cloud infrastructure.
• Databases.
• Storage.
• Authentication.
• AI model providers.
• Payment processors.
• Email providers.
• Analytics providers.
• Security services.
• Networking providers.

An outage or degradation at a third-party provider may affect Asiyst Services.

AI functionality may depend on third-party AI providers.

AI provider issues may result in:

• Failed requests.
• Increased response times.
• Reduced model availability.
• Rate limiting.
• Model-specific errors.
• Temporary unavailability.

Asiyst may use alternative providers or models where technically and operationally appropriate, but does not guarantee that an alternative will always be available.

Customers using their own AI provider accounts are responsible for the availability and operational status of those provider accounts.

An outage, quota limitation, account restriction, or configuration problem at a customer-selected provider may affect the customer's use of Asiyst.

Payment and billing functionality may depend on external payment providers.

A payment-provider outage may affect:

• Purchases.
• Credit recharges.
• Subscription transactions.
• Refund processing.
• Payment verification.

Asiyst may not be able to resolve issues caused entirely by an external payment provider.

Authentication may depend on infrastructure or authentication providers.

Authentication issues may prevent users from:

• Logging in.
• Creating accounts.
• Recovering access.
• Accessing protected resources.

API availability may be affected by:

• Infrastructure.
• Authentication.
• Rate limits.
• Maintenance.
• Security controls.
• Third-party dependencies.
• Network conditions.

API-specific commitments may be governed by the applicable API Terms or Service Level Agreement.

SDK functionality may depend on:

• Asiyst APIs.
• Customer application environments.
• SDK versions.
• Customer dependencies.
• Network connectivity.

An SDK installation or runtime issue does not necessarily represent an outage of Asiyst Services.

The Asiyst CLI may depend on:

• Asiyst APIs.
• User credentials.
• Local network access.
• Local operating-system functionality.
• Installed dependencies.
• Customer configuration.

Problems within a user's local environment may not constitute an Asiyst Service outage.

The Asiyst website and dashboard may experience interruptions independently of API or backend availability.

For example, a dashboard issue may occur while API services remain operational.

Availability may differ based on:

• Geographic location.
• Network conditions.
• Infrastructure region.
• Regulatory restrictions.
• Third-party provider availability.

Certain features may not be available in every country or region.

Asiyst does not control the public Internet, telecommunications networks, local networks, or customer Internet connections.

Network problems outside Asiyst's infrastructure may affect the ability to access the Services.

Customer-controlled systems may affect availability.

Examples include:

• Firewalls.
• DNS configuration.
• Browser restrictions.
• Proxy configuration.
• Local network restrictions.
• Application configuration.
• Incorrect API credentials.
• Customer-side software failures.

Such issues may not constitute Asiyst downtime.

Service functionality may vary depending on:

• Browser.
• Operating system.
• Device.
• Browser extensions.
• Network configuration.
• Software versions.

Customers should use supported configurations where applicable.

Asiyst may temporarily restrict or disable functionality to protect the platform from:

• Security attacks.
• Abuse.
• Fraud.
• Credential compromise.
• Malicious activity.
• Vulnerabilities.

Security-related restrictions may be necessary even if they temporarily reduce availability.

Rate limits, traffic controls, authentication requirements, and other protections may affect request availability.

These controls are intended to protect the Services and users.

APIs and other services may be subject to rate limits.

Requests exceeding applicable limits may be rejected, delayed, or otherwise restricted.

Rate limits may change based on:

• Plan.
• Service.
• System capacity.
• Security requirements.
• Customer configuration.

Certain Services may have technical limits relating to:

• Requests.
• Storage.
• File sizes.
• Processing.
• AI usage.
• API usage.
• Concurrent operations.

Exceeding a limit may affect the availability of the applicable functionality.

High traffic or unusual demand may affect Service performance.

Asiyst may implement temporary controls such as:

• Rate limiting.
• Queueing.
• Traffic management.
• Resource allocation.
• Temporary restrictions.

Some functionality may operate asynchronously.

Examples include:

• Knowledge-source indexing.
• File processing.
• AI processing.
• Analytics processing.
• Data synchronization.

A processing delay does not necessarily indicate a complete Service outage.

Certain Services may depend on background jobs or asynchronous processing.

Failures or delays in these jobs may result in temporary differences between user actions and displayed results.

Connected integrations may not always update instantaneously.

Synchronization may be affected by:

• Provider availability.
• Rate limits.
• Network failures.
• API changes.
• Large data volumes.
• Authentication issues.

Asiyst may modify, upgrade, replace, or discontinue portions of its Services.

Where required, applicable contractual commitments will govern the relevant changes.

Not every feature is necessarily available to every user.

Feature availability may depend on:

• Account type.
• Subscription.
• Region.
• Product version.
• Eligibility.
• Beta access.
• Technical requirements.

Beta and experimental features may have lower availability or reliability than generally available Services.

Such features may be:

• Modified.
• Restricted.
• Temporarily unavailable.
• Discontinued.

Additional terms may apply under the Beta / Experimental Features Terms.

Asiyst may deprecate APIs, SDK versions, features, integrations, or other functionality.

Where reasonably practical, Asiyst may provide information about significant deprecations through applicable documentation or communication channels.

API versions may be changed or deprecated according to applicable API documentation and terms.

Customers are responsible for maintaining compatibility with supported versions.

Asiyst may maintain internal recovery procedures for applicable systems.

Specific recovery targets may vary depending on:

• Service.
• System importance.
• Incident severity.
• Infrastructure.
• Third-party dependencies.

Unless expressly stated in a Service Level Agreement, internal recovery objectives do not constitute contractual guarantees.

Backups may be used to support recovery from:

• Infrastructure failures.
• Data corruption.
• Security incidents.
• Operational errors.
• Other disruptions.

Backup restoration may take time and may not immediately restore every system or feature.

Asiyst may take additional measures to protect data integrity during significant incidents.

These may include:

• Temporarily restricting writes.
• Isolating systems.
• Validating restored data.
• Reprocessing failed operations.
• Rebuilding indexes.

A failed API or application request does not necessarily indicate permanent data loss.

Depending on the operation, customers may be able to retry the request.

Customers should use appropriate idempotency or retry mechanisms where supported.

Customers are responsible for designing applications to safely handle retries where applicable.

Repeated requests may result in repeated operations unless the applicable API provides idempotency controls.

Customers using APIs, SDKs, or integrations should monitor their own applications and usage.

Customer monitoring may help identify:

• Authentication problems.
• Rate-limit issues.
• Integration failures.
• Increased error rates.
• Configuration problems.

Customers may consult the applicable Asiyst status page or support channel when investigating suspected platform-wide incidents.

During significant incidents, Asiyst may prioritize restoration of core Services and may provide support updates through available channels.

Support response times may vary depending on:

• Incident severity.
• Number of affected users.
• Support volume.
• Available resources.

Contractual support commitments, where applicable, are governed by the relevant agreement.

Where a Service Level Agreement applies, the SLA may establish specific availability commitments, exclusions, service credits, measurement methods, and remedies.

The SLA controls only to the extent expressly stated in that agreement.

Where an availability commitment applies, availability may be measured according to the methodology specified in the applicable SLA or service agreement.

Status-page information is not necessarily the contractual measurement used for SLA purposes.

Where applicable under an SLA, certain events may be excluded from availability calculations.

Examples may include:

• Scheduled maintenance.
• Emergency maintenance.
• Customer-caused failures.
• Third-party failures.
• Internet failures.
• Force majeure events.
• Abuse-related restrictions.
• Unsupported configurations.

The applicable SLA controls the actual exclusions.

Availability may be affected by events outside Asiyst's reasonable control, including:

• Natural disasters.
• War.
• Civil disturbances.
• Government actions.
• Internet-wide failures.
• Telecommunications failures.
• Major infrastructure failures.
• Widespread cybersecurity events.
• Other extraordinary events.

The treatment of such events is subject to applicable agreements and law.

Even when a Service is classified as operational, individual requests may fail because of:

• Invalid input.
• Configuration errors.
• Rate limits.
• Authentication problems.
• Third-party dependencies.
• Network issues.
• Software defects.

Operational status does not mean that every request will succeed.

Asiyst uses measures intended to reduce the risk of data loss, but no system can eliminate all risk.

Customers should maintain appropriate copies or exports of critical information where necessary.

Customers may use available export functionality to retain copies of applicable information.

Export availability depends on the applicable Service and data type.

Additional information is provided in the Export & Data Portability Policy.

If a Service or feature is permanently discontinued, Asiyst may provide information concerning the discontinuation where appropriate.

Data export, retention, and deletion following termination are governed by applicable policies and agreements.

Asiyst may use one or more channels to communicate operational information, including:

• Status pages.
• Email.
• Dashboard notifications.
• Documentation.
• Support channels.
• Other appropriate communication methods.

Status information is provided based on information available at the time.

During an active incident, information may be incomplete or change as the investigation develops.

Security controls may occasionally reduce availability.

For example, Asiyst may temporarily restrict access to protect systems from a suspected attack.

Such measures may be necessary to protect the broader Service.

Operational monitoring may involve processing technical information, account information, request metadata, and other information necessary to identify and resolve service issues.

Such information is handled according to applicable privacy and security policies.

When a third-party provider materially affects an Asiyst Service, Asiyst may consider the provider's operational status when investigating or communicating an incident.

Third-party status information may not always be complete or immediately available.

During an outage or degradation, customers should:

• Check applicable status information.
• Review their own application logs.
• Verify credentials and configuration.
• Check third-party dependencies.
• Avoid unnecessary repeated requests.
• Contact support where appropriate.

Asiyst may update this Service Availability / Status Policy as its Services, infrastructure, operational practices, or contractual commitments change.

The current version will be made available through the applicable Asiyst website or service.

This policy should be read together with:

• Service Level Agreement.
• Security Policy.
• Security & Trust Center.
• Incident Response & Security Breach Policy.
• API Terms.
• Developer Terms.
• Terms of Service.
• Beta / Experimental Features Terms.
• Payment Terms.
• Privacy Policy.

Where a separate written agreement contains specific availability commitments, that agreement governs the applicable commitment to the extent expressly stated.

Questions regarding service availability, operational incidents, or status information should be submitted through the applicable Asiyst support or service-status contact method.