Basic Information #

• Established: 2025-12-24
• Revised: 2026-02-19
• Effective Date: 2026-02-19
• Service Provider: BESTNET LLC (hereinafter “the Company”)
• Address: 161-1 Kitanagane, Aza Onuki, Tajiri, Osaki City, Miyagi Prefecture
• Contact:
  • General Support: Support Tickets
  • Abuse Reporting: This Form

Article 1 (Application) #

1. These Terms set forth the conditions of use for all services provided by the Company, including virtual private servers (VPS), GPU-VPS, cloud/IaaS, hosting, and associated network/storage/backup/snapshot/ISO-related functions/API, etc. (hereinafter collectively referred to as “the Service”). Separate terms of use shall apply to domain name registration services and SSL certificate issuance services provided by the Company.
2. These Terms include Standard Support Conditions (Annex A) and SLA/Service Credit Conditions for Outages (Annex B).
3. The Service may have “Individual Conditions” that specify service-specific specifications (CPU/memory/storage/bandwidth, etc.), fees, scope of provision, and other specific terms. Where Individual Conditions conflict with these Terms (main text or annexes), the Individual Conditions shall take precedence.
4. However, for Article 13 (Handling of IP Addresses, etc.), Article 14 (Modification, Suspension, or Termination of the Service), Article 15 (Amendment of Terms), and Article 16 (Disclaimer and Limitation of Liability), when Individual Conditions provide for handling different from these Terms, the Company shall expressly state in such Individual Conditions that they supersede these Terms.
5. When a Customer applies for or uses the Service, the Customer shall be deemed to have agreed to these Terms and Individual Conditions.

Article 2 (Definitions) #

Terms in these Terms are defined as follows:

(1) “Customer”: An individual or corporation using the Service
(2) “Account”: An identifier issued by the Company for using the Service
(3) “Usage Environment”: The area used by the Customer on the Service (e.g., virtual machines, containers, hosting accounts, storage areas, etc.). Where “instance” is used in these Terms, it includes the Usage Environment.
(4) “Assigned IP”: IP address (including fixed/32, etc.) assigned by the Company to the Customer or Usage Environment
(5) “Fixed IP”: An operational form in which the Company normally continues to assign the same Assigned IP. However, even Fixed IPs may be changed or suspended pursuant to Article 13 and Article 14.
(6) “Upstream Provider”: Line carriers, ISPs, transit providers, IXs, data center operators, and other third-party providers used by the Company to provide the Service.
(7) “Communication”: All network communications related to the Usage Environment, including inbound/outbound
(8) “Abuse”: Acts that violate these Terms (including Article 5) or acts that the Company reasonably determines to be abuse
(9) “Tiered Operation (Trust Level)”: The operational categories (new/proven/corporate) defined in Article 10
(10) “Credit”: A monetary equivalent amount recorded in a Customer’s Account pursuant to separately established regulations by the Company, which can be applied to payments for the Service within the scope defined by the Company.
(11) “Service Credit”: Credits granted as compensation for SLA violations, etc., or at the Company’s discretion.
(12) “Standard Support”: The standard support defined in Annex A.
(13) “SLA”: The uptime guarantee and service credit conditions defined in Annex B.

Article 3 (Application, Account Management, and Verification Procedures) #

1. For secure operation and abuse prevention, the Company may require identity verification/corporate verification/contact verification/confirmation of intended use, etc. (hereinafter “Verification Procedures”) at the time of application or during use.
2. When requested by the Company to undergo Verification Procedures, the Customer shall submit truthful and accurate information within a reasonable period. In cases of falsehood, deficiency, or inconsistency, the Company may reject applications, suspend use, downgrade tiered operations, impose additional restrictions, etc.
3. The Customer shall maintain registered contact information (email/telephone, etc.) with the Company in a state capable of receipt at all times. If inability to contact continues, the Company may impose restrictions pursuant to Article 7 (Communication Restrictions and Technical Measures) and Article 10 (Tiered Operation), or suspension pursuant to Article 14 (Modification, Suspension, or Termination of the Service) for secure operation.

Article 4 (Shared Responsibility and Security) #

1. The Company shall endeavor to maintain the security of Company equipment, networks, and control infrastructure.
2. The Customer shall be responsible for protection of OS/middleware/applications/authentication information/keys/configuration/data on the Usage Environment (for hosting, etc., the scope managed by the Company shall follow Individual Conditions).
3. The Customer shall implement appropriate security measures including the following:
   (1) Continuous application of patches to OS, middleware, and applications (excluding areas managed by the Company)
   (2) Non-use of default authentication information, use of strong authentication (keys, strong passwords, MFA where possible, etc.)
   (3) Stopping unnecessary services, minimizing exposed ports
   (4) Implementation of access source restrictions for administrative access (e.g., SSH/RDP, etc.) (where possible)
   (5) Prompt blocking and recovery response and contact to the Company when compromise is suspected
4. If abuse occurs due to Customer deficiencies (e.g., weak configuration, key leakage, misconfigured public settings, etc.), the Company may take necessary measures pursuant to Article 7 and Article 12.

Article 5 (Prohibited Acts: Acceptable Use Policy / AUP) #

Customers shall not engage in the following acts using the Service.

5.1 Legal Violations and Rights Infringement #

(1) Acts violating laws and regulations (including unauthorized access, fraud, threats, illegal drugs, child sexual exploitation, money laundering, etc.)
(2) Acts infringing on copyrights, trademark rights, privacy, trade secrets, or other third-party rights
(3) Use that violates sanctioned countries/regions or export regulations designated by the Company

5.2 Unauthorized Access, Malware, and Intrusion Acts #

(1) Unauthorized access, intrusion, vulnerability exploitation, privilege escalation to systems of the Company or third parties
(2) Creation/distribution/operation of malware (viruses, worms, ransomware, etc.), operation of C2 (Command & Control)
(3) Phishing, spoofing, theft of authentication information, operation of fraudulent sites
(4) Construction, operation, relay of, or participation in botnets

5.3 Spam and Nuisance Acts #

(1) Spam email transmission, email relay (open relay), unauthorized mass messaging
(2) Nuisance acts using SMS/IM/forms, etc., unauthorized advertising, harassment
(3) Acts causing nuisance or damage to third parties through mass account creation, etc.

5.4 Network Abuse and Interference #

(1) DDoS/DoS, port scanning, vulnerability scanning, brute force, and other attack activities
(2) Providing public proxy/VPN/stepping stone to third parties (except where expressly permitted by the Company)
(3) Source spoofing, header spoofing, IP spoofing, routing interference, etc.
(4) Excessive bandwidth, connections, or packet transmission causing disruption to the Company, upstream lines, or other users

5.5 Service/Control Circumvention #

(1) Circumventing or disabling communication restrictions, rate limits, monitoring, or blocking measures established by the Company
(2) Billing circumvention, authentication circumvention, improper resource exhaustion (mass creation, mass requests, etc.)
(3) Reselling, subleasing, or hosting to third parties without the Company’s permission (except where permitted by the Company in reseller plans, etc.)

5.6 Other #

(1) Acts damaging the reputation of the Company or third parties, acts concentrating complaints or reports
(2) Acts that the Company reasonably determines to constitute abuse

Article 6 (Handling of Security Testing) #

1. When a Customer conducts security testing (diagnostics, penetration testing, scanning, etc.), the scope is limited to assets for which the Customer has administrative authority.
2. For DDoS resilience testing, wide-range scanning, tests that may affect third parties, etc., the Customer shall apply in advance using the method prescribed by the Company and obtain approval.
3. We may request cessation or modification of testing methods if we determine that it affects other users or upstream services.

Article 7 (Communication Restrictions and Technical Measures) #

1. We may implement the following measures without prior notice to customers (in emergencies, notification may be provided after the fact) to maintain the security of the Service, prevent unauthorized use, and respond to upstream provider requests:
   (1) Blocking or restricting specific ports/protocols
   (2) Limiting bandwidth, number of connections, transmission rates, etc., and temporary blocking of communications (isolation/quarantine)
   (3) Temporary suspension of the usage environment, network disconnection, temporary suspension/change of assigned IPs (when necessary)
   (4) Acquisition and preservation of logs (including evidence preservation)
2. The standard permitted scope of outbound (transmission) communications and handling of additional permissions are defined in Article 8.
3. We may revise the content of Article 8 or temporarily modify the standard permitted scope (additional blocking/isolation, etc.) in response to detection status, upstream requests, legal compliance, etc. (notification will be provided in accordance with Article 15; however, in emergencies, notification may be provided after the fact).

Article 8 (Standard Permitted Scope and Additional Permissions for Outbound Communications) #

8.1 Purpose #

This Article defines the “standard permitted scope of outbound (transmission) communications” implemented by us at the network level to prevent abuse, maintain IP reputation, respond to upstream network requests, and ensure stable operation of our infrastructure.

8.2 Basic Policy (Whitelist) #

(1) Outbound communications from customer usage environments to the Internet shall be permitted only for communications explicitly allowed by us.
(2) Outbound communications not explicitly stated in this Article shall in principle be blocked.
(3) We may temporarily modify the permitted scope of this Article (additional blocking/isolation, etc.) without prior notice to customers based on detection status, upstream network requests, legal compliance, or security judgments (notification after the fact in emergencies).

8.3 Standard Permissions (Communications Permitted by Default: Common to All Trust Levels) #

The following are “standard permissions (default permissions)” common to all services and all trust levels.

8.3.1 DNS (Name Resolution: Outbound) #

• UDP 53 (DNS)
• TCP 53 (DNS: fallback/large responses, etc.)
  Note: We may restrict DNS destinations to only our designated resolvers as necessary.

8.3.2 NTP (Time Synchronization: Outbound) #

• UDP 123 (NTP)
  Note: We may restrict NTP destinations to only our designated servers as necessary.

8.3.3 Web Access (General Software Updates, API Usage, etc.: Outbound) #

• TCP 80 (HTTP)
• TCP 443 (HTTPS)
• UDP 443 (QUIC / HTTP/3)

8.3.4 ICMP (Connectivity and Routing Control: Inbound / Outbound) #

• ICMP (IN/OUT) is permitted as standard.
  Note:
  ・We may restrict ICMP types (Type/Code) for attack countermeasures, anomaly detection, upstream requests, etc.
  ・Standard permissions are intended for connectivity/routing control purposes, and may be subject to restrictions if abuse is suspected.

※Outbound communications not explicitly stated above shall in principle be blocked.

8.4 Additional Outbound Permissions (Application-Based: Common to All Trust Levels) #

(1) If customers require outbound communications (ports/protocols) other than those permitted as standard, they shall apply through our designated method and obtain our approval.
(2) We shall comprehensively review the legitimacy of the purpose of use, ability to identify destinations, expected traffic volume, risk of unauthorized use, customer trust level, etc., and determine approval/denial/conditional approval.
(3) Examples of conditional approval (at our discretion):

• Restrictions on destination IP/network/country/provider, etc.
• Limits on transmission rates and concurrent connections
• Time-limited permissions (for verification purposes, etc.)
• Automatic isolation upon anomaly detection (degradation to standard permissions only)

(4) Even after approval is granted, we may modify conditions or re-block if there are reports, anomaly detections, upstream requests, etc.

8.5 Application Template #

When applying, please submit the following (if incomplete, the review may be suspended/denied):

• Port/protocol to be applied for (e.g., TCP 22 / TCP 587, etc.)
• Destination (to the extent possible): destination IP/range, service name, country/provider, etc.
• Purpose of use: why it is necessary (specifically)
• Usage period: permanent/temporary (period)/verification
• Expected transmission volume: estimated per hour/per day
• Security measures: authentication method, access control, log acquisition, shutdown procedure
• Contact information: technical contact and abuse response contact (mandatory for corporations)

8.6 Handling of High-Risk Uses (Email Transmission, etc.) #

We conduct particularly strict reviews for high-risk uses such as email transmission to prevent spam transmission and IP reputation damage.
We recommend the use of external authenticated email relays (SMTP Relay/Submission), etc., and may impose conditions such as destination and rate restrictions as necessary.
We may not grant additional permissions for ports required for such uses if we determine the risk to be high.

Article 9 (Monitoring and Logs) #

1. We may acquire and preserve communication logs, connection information, operation history, etc. for the purposes of preventing unauthorized use, responding to failures, maintaining quality, responding to upstream requests, etc.
2. We may provide necessary information to relevant authorities, upstream providers, or related parties within the scope of applicable laws when required by law, requested by upstream providers, or when necessary to respond to unauthorized use.

Article 10 (Staged Operations: New/Established/Business) #

10.1 Purpose #

To suppress abuse that tends to occur in low-price services, maintain IP reputation, and ensure infrastructure stability, we apply staged operations (trust levels) on an account or service basis.

10.2 Categories #

(A) New (New / Trial)
(B) Established (Established)
(C) Business (Business / Corporate)

10.3 Common Matters (Important) #

(1) Standard permitted (default permitted) outbound communications are common to all trust levels (Article 8).
(2) Differences by trust level primarily appear in the review criteria and strictness of conditions for “additional outbound permissions (application-based).”
(3) If there are signs of unauthorized use, reports, upstream requests, etc., we may implement measures such as additional blocking/isolation/suspension regardless of trust level (Article 7).

10.4 Treatment of Each Category (Review Policy for Additional Outbound Permissions) #

10.4.1 New (New / Trial) #

• Additional outbound permissions: in principle, cautious review
• Form of permission: conditional permissions (destination restrictions, rate limits, time limits, etc.) may be granted only when necessity is high
• Purpose: to suppress concentration of abuse immediately after launch

10.4.2 Established (Established) #

• Additional outbound permissions: may be granted upon application (expanded approval scope compared to new accounts)
• Form of permission: conditional permissions (destination restrictions, rate limits, enhanced monitoring, etc.) may be imposed
• Purpose: to balance convenience of normal use with risk management

10.4.3 Business (Business / Corporate) #

• Additional outbound permissions: broad consideration upon application, assuming clear business content, responsibility structure, and abuse response contact
• Form of permission: conditional permissions (rate limits, monitoring/log provision, destination restrictions, time limits, etc.) may be imposed
• Purpose: to provide communications necessary for business purposes through individual review while maintaining overall infrastructure security

10.5 Upgrade/Downgrade #

(1) Upgrades are granted at our discretion or upon application. We may require verification procedures (identity/corporate verification, contact verification, usage purpose confirmation, etc.).
(2) We may downgrade, restrict, or suspend without notice in the following cases:

• AUP violations or suspicion thereof, frequent reports, warnings from upstream providers
• Inability to contact, non-cooperation with verification procedures, false declarations
• Serious security incidents, continued state of unresolved compromise
• Material contractual non-compliance (such as non-payment)

10.6 Application and Review (Common) #

(1) Applications for additional outbound permissions shall be submitted via support ticket or other methods designated by us.
(2) We may request submission of additional materials, or suspend/reject the review if the submitted content is insufficient.
(3) Even after granting permission, we may change conditions or re-block if there are signs of abuse or upstream requests.

Article 11 (Reports and Incident Response) #

1. When we detect suspected abuse or receive a report from a third party/upstream provider, we may take the following actions:
   (1) Request additional information (usage purpose, configuration status, relevant logs, etc.)
   (2) Provisional measures such as traffic restrictions, isolation, suspension of usage environment
   (3) Request corrective measures (configuration changes, compromise response, reconstruction, etc.)
2. Customers shall respond to our inquiries within a reasonable period and perform necessary corrections.
3. In cases of serious abuse, we may cooperate with relevant authorities, upstream providers, security organizations, etc., and provide necessary information within the scope of applicable laws.

Article 12 (Measures for Violations) #

1. If a customer violates this Agreement or there is a reasonable degree of suspicion thereof, we may implement the following measures progressively or immediately:
   (1) Warning, request for correction
   (2) Traffic restrictions, port blocking, isolation, rate limiting
   (3) Suspension of usage environment, account suspension, contract termination
   (4) Billing for reasonable costs incurred in investigation and response (when necessary)
2. We may suspend release/restoration until suspicion of abuse is resolved.

Article 13 (Handling of IP Addresses, etc.) #

1. Assigned IPs are number resources designated and managed by us, and customers do not acquire ownership, permanent guarantee of usage rights, transferable rights, or other similar rights to assigned IPs.
2. We may change assigned IPs (including fixed IPs) or suspend their use when necessary for providing this service, including but not limited to the following reasons:
   (1) Prevention of abuse, security needs (including Articles 7, 11, and 12)
   (2) Requests from upstream providers, changes in provision conditions, changes in lines/equipment/locations
   (3) Requests for return of number resources, reorganization of number resources, technical or operational needs (including planned renewals)
   (4) Cases where we or upstream providers deem it necessary due to IP reputation damage, blacklist registration, frequent complaints/reports, etc.
3. When we change assigned IPs, we will give advance notice whenever possible if we can anticipate it. However, in emergency situations or due to upstream provider circumstances where advance notice is difficult, notification may be given after the fact.
4. Customers shall manage configurations dependent on assigned IPs (e.g., whitelists, VPN peers, ACLs, external integrations, SPF/DKIM/DMARC, reverse DNS, etc.) themselves, and prepare for assigned IP changes by using DNS names, implementing redundancy, establishing migration procedures, etc.
5. When we provide configurations associated with assigned IPs such as reverse DNS (PTR), the scope, conditions, and ability to change such configurations shall be subject to individual conditions. We do not guarantee the provision or maintenance of such configurations due to upstream provider constraints, technical constraints, etc.
6. Upon contract termination or notification from us to suspend use of an assigned IP, customers shall promptly cease use of that assigned IP (including advertising, configuration, service provision, display to third parties, etc.).

Article 14 (Changes, Interruptions, and Discontinuation of This Service) #

1. We may change the content (including changes to specifications, functions, provision conditions, restrictions, and pricing structure), interrupt provision, or discontinue all or part of this service based on our reasonable judgment, including but not limited to the following reasons:
   (1) Changes in upstream provider provision conditions, termination of provision, equipment removal, location closure, line suspension, etc.
   (2) Response to laws, regulations, administrative guidance, etc.
   (3) Security needs, response to serious incidents
   (4) Equipment renewal, maintenance, fault response, disasters, or other force majeure
   (5) Other cases where we determine that stable provision of this service is difficult
2. When we change, interrupt, or discontinue this service based on the preceding paragraph, we will give advance notice whenever possible if we can anticipate it. However, in emergency situations or due to upstream provider circumstances where advance notice is difficult, notification may be given after the fact.
3. We will endeavor to provide information regarding the scope of impact, migration policy, recommended procedures, etc., associated with changes, interruptions, or discontinuation, to the extent reasonably possible. However, configuration changes in customer environments, migration work, changes on external service sides, etc., shall in principle be the customer’s responsibility (except when we separately undertake such work through paid support, etc.).
4. In preparation for service interruptions, discontinuation, etc., customers shall implement backups of important data, redundancy, establishment of migration plans, etc., on their own. Customer data may be lost or become unavailable due to interruptions or discontinuation.
5. The handling of settlement and refunds when we discontinue this service shall be subject to individual conditions and provisions separately established by us regarding credits (account credits). If not specified in individual conditions, we will respond by granting credits equivalent to the unused period or by other methods we deem reasonable (however, we may deduct transaction fees, etc.).

Article 15 (Amendment of Agreement) #

1. We may amend this Agreement as necessary.
2. When amending this Agreement, we will announce the amended content and effective date by posting on our website, notification in the client portal, email, or other methods we deem appropriate.
3. For significant changes, we will in principle announce them at least 30 days before the effective date. However, this does not apply in cases of legal amendments, emergency security responses, abuse prevention, system fault response, or other urgent and unavoidable situations, or in the case of minor changes that benefit customers, and such amendments may be applied through post-facto announcement or short-term announcement.
4. The amended Agreement shall apply from the effective date announced by us. If a customer uses this service after the effective date, the customer shall be deemed to have agreed to the amended Agreement (subject to limitations under applicable laws).
5. If a customer does not agree to the amended Agreement, the customer shall complete cancellation or other procedures by the method designated by us before the effective date (cancellation conditions shall be subject to individual conditions).

Article 16 (Disclaimer and Limitation of Liability) #

1. We shall not be liable for damages incurred by customers due to blocking, restrictions, suspensions, etc., implemented to prevent abuse, and measures based on Article 13 (Handling of IP Addresses, etc.) and Article 14 (Changes, Interruptions, and Discontinuation of This Service), unless caused by our willful misconduct or gross negligence (subject to limitations under applicable laws).
2. Due to the nature of this service, communication quality and reachability may fluctuate due to internet conditions, upstream line factors, third-party factors, etc. We do not guarantee specific communication quality, reachability, latency, loss rates, or specific routes.
3. Even if we bear liability for damages (except in cases of our willful misconduct or gross negligence), the scope of our liability for compensation shall be limited to direct and ordinary damages, and we shall not be liable for lost profits, loss of business opportunities, data loss, indirect damages, special damages, or consequential damages.
4. Notwithstanding the preceding paragraph, if our liability for compensation is recognized (except in cases of our willful misconduct or gross negligence), the upper limit of our liability for compensation shall be the amount equivalent to the usage fees paid by the customer to us in the month preceding the month in which the damage occurred for the service that caused the damage (or if there is no payment record for the preceding month, the amount equivalent to the usage fees payable in the month the damage occurred) (subject to limitations under applicable laws).

Article 17 (Governing Law and Jurisdiction) #

1. This Agreement shall be governed by the laws of Japan.
2. All disputes arising between us and you in connection with these Terms or the Service shall be subject to the exclusive jurisdiction of the Furukawa Branch of the Sendai District Court as the court of first instance.

Annex A: Standard Support Terms #

Appendix B: SLA (99.9% / Service Credits for Incidents) #

Last Updated: 2026-02-17

1. Scope of Application #

This Appendix applies to the BESTNET CLOUD/VPS Service (hereinafter “SLA-Covered Services”) provided by us. SLA-Covered Services are limited to those for which we have clearly stated SLA coverage on our sales pages or elsewhere.
When using SLA-Covered Services, the contents of this Appendix apply as specific terms under the main Terms of Service.
In the event of a conflict between the main Terms and this Appendix, this Appendix takes precedence only for matters related to “uptime guarantees and service credits.”

2. SLA Overview #

We guarantee a monthly uptime of 99.9% (hereinafter “SLA Value”) for this service.
If uptime falls below the SLA Value, we will grant account credits (service credits) via our client portal to eligible customers.

3. Definitions #

3.1 Availability #

Availability is calculated for each calendar month (Japan Standard Time, JST) using the following formula:

• Availability (%) = 100 × (Total Provided Time − Downtime) ÷ Total Provided Time
• Total Provided Time: Total minutes in the month (e.g., 30 days = 43,200 minutes)
• Downtime: Time (in minutes) that qualifies as “Outage” as defined by us and does not fall under “SLA Exclusions”

3.2 Outage #

“Outage” means a condition in which the service is continuously unavailable as determined by our monitoring systems.
Intermittent events under 5 minutes may not be counted toward downtime (to ensure measurement stability).

3.3 Downtime #

Downtime is calculated by us based on records from our monitoring systems.
If there is a discrepancy with the customer’s measurements, our calculation takes precedence.

4. SLA Exclusions (Events Not Counted Toward Downtime) #

Downtime does not include (and SLA compensation does not apply to) the following cases:

• Incidents caused by customer OS configuration, middleware, applications, databases, etc.
• Incidents caused by customer actions (including configuration changes, deletions, resource exhaustion)
• Scheduled maintenance announced by us in advance (including equipment upgrades, network switches, data center relocations, assigned IP changes/renewals)
• Emergency maintenance (e.g., security responses) for which we provide necessary post-event notification
• External factors (upstream carrier incidents, upstream provider terms changes/termination, number resource reclamation requests, Internet-wide incidents, DDoS, third-party attacks, natural disasters, etc.)
• Events arising from or related to measures based on our common Terms of Service (main text of these Terms), such as communication restrictions, isolation, suspension, changes/suspension of assigned IPs for fraud prevention, upstream provider requests, legal compliance, etc.
• Free components or services otherwise designated by us as excluded

5. Service Credit (Compensation) Details #

5.1 Form of Compensation #

Compensation is provided as account credit in our client portal.
We do not provide cash refunds, card refunds, bank transfers, etc.
The handling of service credits (nature, expiration, final settlement, etc.) is subject to our separately defined credit regulations.

5.2 Eligible Fees for Compensation #

Compensation applies to the base monthly fee for this service for the applicable month.
(Usage-based charges, late fees, administrative fees, etc. may be excluded)

5.3 Credit Calculation Method #

Let M (minutes) be the total minutes in the applicable month and D (minutes) be the downtime.

• SLA Violation Determination:
  • If D > ⌈M × 0.001⌉, it is determined that the SLA value (99.9%) has been violated
  • ⌈ ⌉ represents rounding up (in minutes)
• Allowed Downtime:
  • T = ⌈M × 0.001⌉
• Excess Downtime:
  • E = D − T (if E is 0 or less, then 0)
• Credit Rate (%):
  • Credit Rate = min(100, ⌈E ÷ 30⌉ × 5)
• Credit Amount Granted:
  • Credit Amount = Base Monthly Fee × Credit Rate

Example (30-day month: M=43,200 minutes → T=44 minutes) #

• 44 minutes downtime: Within SLA → 0%
• 50 minutes downtime: 6 minutes excess → ⌈6/30⌉=1 → 5%
• 80 minutes downtime: 36 minutes excess → ⌈36/30⌉=2 → 10%
• 200 minutes downtime: 156 minutes excess → ⌈156/30⌉=6 → 30%

5.4 Cap #

The service credit cap is 100% of the base monthly fee for the applicable month.

6. Application (Claim) Process #

To receive a service credit, the following conditions must be met:

• Submit an application to the support desk (ticket) within 30 days of the incident occurrence (or our announcement)
• Clearly specify the applicable service (contract ID, etc.), occurrence time, and impact details
• Your customer account must be in a valid contract status without payment delays, etc.

※If no application is submitted, automatic credit may not be granted.

7. Credit Grant Timing #

After we review the application and approve its eligibility, we will grant the account credit within a reasonable period as a general rule.
(Completion notification will be provided via ticket)

8. Disclaimers and Other Matters #

• The service credits specified on this page constitute the sole and exclusive remedy for SLA violations.
• Disclaimers, limitation of liability, and other matters related to this service are subject to our common Terms of Service (main text of these Terms).
• We may modify the contents of this page. Modified contents will be announced on our website with the effective date, and will apply from the effective date onward (subject to restrictions under applicable law).