Proposed launch terms, not yet effective. Company details and service-specific commitments must be confirmed before live orders. The sections below describe the proposed policy in full.
On this page
1. What this agreement covers
This service-level framework describes how the availability of an eligible Starcloud cloud server is assessed and how an incident claim is handled. A binding availability target, claim window and credit schedule apply only when expressly included with the accepted service order.
The framework concerns the supplied compute service and its associated network access. It does not extend automatically to your application, operating system, internet connection or third-party services you install. Demonstration services are excluded because they do not provision production infrastructure.
2. Availability and eligible downtime
Eligible downtime is a verified period during which the covered server service cannot perform its covered function because of an issue within the service scope, after applying the exclusions in the accepted schedule. Failure of a website or login attempt is evidence to investigate, not by itself proof that the whole server was unavailable.
An incident begins at the first supported time of the qualifying failure and ends when the covered function is restored. Repeated observations of the same continuous interruption form one interval. Overlapping incidents must not count the same minute more than once.
A stopped server, a blocked source IP or an application refusing a connection requires a different assessment from an unavailable host or network path. The cause and affected component should be recorded with the result.
3. Measuring monthly availability
For a covered billing month, availability is calculated as 100 × (eligible minutes − eligible downtime minutes) ÷ eligible minutes. Eligible minutes are the time the service was active and covered during that month, excluding only periods the accepted schedule expressly removes from measurement.
Measurements should use a consistent time zone and distinguish partial-month service, duplicate reports and overlapping failures. If there are no eligible minutes, the monthly percentage is not applicable. Rounding should not hide a failure to meet an agreed threshold.
Service records, network observations and customer-supplied logs should be considered together. An external probe can help establish timing, but a failure from one location may reflect a problem outside the covered service. The assessment should explain material differences between records.
4. Events outside the covered service
Subject to the accepted schedule and applicable law, excluded causes may include your own shutdown instruction, operating-system changes, an incorrect firewall rule, lost credentials, malware within your application or exhaustion of the resources you selected.
Connectivity problems outside the covered network, third-party software and properly authorised service restrictions may also fall outside coverage. An exclusion should be tied to the actual cause and duration, not used as a blanket reason to reject an incident.
Maintenance, external attacks and exceptional events are not automatically unlimited exclusions. Their treatment must be stated in the applicable service-level schedule. A service dependency being operated by another supplier does not, on its own, settle whether a failure is covered.
5. Maintenance and incident communications
Planned work that is expected to affect service should be communicated through the available account or service-notification channel where practical. The notice should identify the affected service, expected window and any action required from you.
Emergency work may be necessary without advance notice to address an active security issue or prevent greater damage. Updates should distinguish an estimate from confirmed restoration. Support response targets and resolution guarantees are separate commitments and apply only when expressly included.
The public status feed is not yet available in this preview. Use the support portal for service questions rather than assuming that the absence of a public incident notice proves availability.
6. Reporting an interruption
Open a support ticket as soon as practical. Include the service identifier, start and end times with time zone, affected function, relevant error messages and any recent configuration changes. Say whether the issue affects all connections or only a particular network or application.
Provide concise logs or measurements that you are authorised to share. Remove passwords, tokens, private keys and unrelated personal information. Keep the original records so the timing can be checked during review. Do not conduct disruptive tests against shared or third-party infrastructure.
7. Credit eligibility and calculation
A credit is due when the verified monthly availability falls below a target in the accepted schedule and its stated claim conditions are met. The schedule must identify the percentage bands, eligible recurring charge, maximum credit and submission window before they govern the order. This draft sets no numerical uptime guarantee or credit tier.
The credit base should be limited to the affected covered service and period, rather than unrelated servers or extras. The same interruption must not generate duplicate credits for the same loss under overlapping claims. Any deduction or cap must follow the schedule and applicable law.
Service credits are applied to eligible future charges unless the accepted terms provide otherwise. They do not eliminate a statutory refund or other non-excludable remedy. A discretionary goodwill adjustment does not establish a new standing availability commitment.
8. Claim review and outcome
To request a credit, identify the relevant incident ticket and billing period, explain the claimed interruption and provide supporting records. The reviewer should confirm the covered service, eligible minutes, verified downtime, exclusions and calculation.
A decision should explain whether the claim qualifies and how any adjustment was determined. If you believe evidence was missed, reply to the same ticket with the specific discrepancy. Response and processing deadlines are those expressly included in your service terms or required by law; this draft does not promise an unverified turnaround time.
9. Data recovery and workload resilience
Availability is different from data durability, backup retention and application recovery time. An availability credit does not promise recovery of a particular file or a specific recovery point. Backup and managed-recovery commitments, if offered, must be described separately.
Maintain independent backups and an appropriate recovery plan for important workloads. A single server is not a redundant application architecture. Choose resilience measures based on the impact of interruption, and verify which responsibilities are yours and which are expressly included in the service.
Questions about this policy?
If you have an account, open a support ticket with the relevant service or invoice reference. Otherwise, check the contact page for available ways to reach us.