Service Level Agreement (SLA)

1. Overview and Scope

This Service Level Agreement ("SLA") describes the uptime commitment, operational targets, and service credits available for Pyro Inc.'s ("Pyro") cloud infrastructure and hosting services. This SLA is incorporated into and forms part of our Terms of Service and applies to customers with active, paid service accounts for covered services.

2. Covered Services and Exclusions

2.1 Covered Services

This SLA applies to the following Pyro-controlled components of active, paid, generally available services where an SLA is offered for the applicable plan, order, checkout page, or service documentation:

Multiplayer server hosting for all supported platforms and titles
Virtual Private Servers (VPS) across all tiers and configurations
Web hosting and application deployment services
Database hosting services including PostgreSQL and other supported databases
Core platform infrastructure, APIs, and management interfaces

2.2 Service Exclusions

This SLA does not cover service interruptions caused by:

Scheduled maintenance with advance notice as defined in Section 6
Customer actions, misconfigurations, or content-related issues
Third-party services, networks, or providers outside Pyro's direct control
Force majeure events beyond our reasonable control (natural disasters, war, pandemic)
Suspension or termination for policy violations or non-payment
Free trials, promotional services, or beta/preview features
Internet connectivity issues between customer location and our network

2.3 Geographic Coverage

SLA commitments apply to eligible paid services hosted in service regions where this SLA is offered, as shown at checkout, in the account dashboard, or in service documentation. Available service regions may change over time.

3. Service Level Commitments

3.1 Uptime Guarantee

Pyro commits to the monthly uptime level stated for the applicable covered service in the relevant plan, order, checkout page, or service documentation. If no specific uptime level is stated for a covered paid service, the default monthly uptime commitment is 99.99% for Pyro-controlled infrastructure components, calculated as:

Uptime Percentage = (Total Minutes in Month - Downtime Minutes) / Total Minutes in Month * 100

3.2 Downtime Definition

"Downtime" means a period of sixty (60) or more consecutive seconds during which the Pyro-controlled infrastructure component of your covered service is unreachable due to issues within Pyro's infrastructure and our monitoring or investigation confirms the outage. Downtime specifically includes:

Complete service unavailability preventing all access
Network connectivity failures within our infrastructure that render the service unreachable

Downtime does not include:

Latency or partial performance degradation where the service remains reachable
Interruptions lasting less than 60 consecutive seconds
Customer-side connectivity or configuration issues
Scheduled maintenance during announced windows
Force majeure events as described in Section 14.3

3.3 Measurement Methodology

Uptime is measured monthly from 00:00 UTC on the first day to 23:59 UTC on the last day
Monitoring occurs from one or more locations at intervals appropriate for the affected service
Automated monitoring systems track service availability and response times where supported
Customer-reported issues are investigated but require verification to constitute Downtime
Measurements exclude announced maintenance windows and customer-caused outages

3.4 Service Restoration Targets

Recovery Time Objective (RTO): We work to restore affected services as quickly as practicable. Restoration time varies by incident, service, plan, customer configuration, and third-party dependency. This is an operational target, not a guarantee.
Recovery Point Objective (RPO): Backup restoration and possible data loss vary by service, plan, backup configuration, and incident. Backups are subject to the best-effort backup terms in Section 8.3, and you remain responsible for maintaining independent backups (Section 8.2). This is an operational target, not a guarantee.
Initial Response: We prioritize Critical severity incidents, as defined in Section 7.3, based on customer impact, severity, available information, and operational capacity.

4. Performance Standards

4.1 Network Performance

Network Uptime: The applicable monthly availability commitment for covered services, subject to Section 3.1 and the exclusions in Section 2.2.
Latency Targets: We use commercially reasonable efforts to manage network latency, but latency varies by region, route, customer location, plan, and third-party networks.
Bandwidth Capacity: Uplink capacity and available throughput vary by location and plan and are not guaranteed unless a specific plan or order states otherwise.
Packet Loss: We use commercially reasonable efforts to limit packet loss under normal operating conditions, but packet loss is not guaranteed unless a specific plan or order states otherwise.

4.2 Security and DDoS Protection

Basic Protection: Included DDoS mitigation up to datacenter capacity (varies by location), subject to attack type, upstream-provider limits, and service configuration.
Advanced Protection: Partnership with TCPShield for enhanced mitigation when needed.
Detection and Mitigation: Automated mitigation is designed to activate promptly after attack detection. This is an operational target, not a guarantee, and depends on the attack, upstream provider, datacenter capacity, and service configuration.
Volumetric Attacks: Multi-layer defense against volumetric attacks, with capacity provided through our datacenter and upstream partners. DDoS mitigation does not guarantee that every attack will be blocked, that service will remain reachable during every attack, or that mitigation will complete within a specific time.

5. Service Credits and Remedies

5.1 Service Credit Calculation

If we fail to meet the applicable uptime commitment, you may be eligible for service credits. Uptime is calculated to three decimal places and is not rounded upward:

Monthly Uptime Achieved	Service Credit Percentage
At least 99.0% and below the applicable commitment	5% of monthly service fees
At least 95.0% and below 99.0%	10% of monthly service fees
Below 95.0%	25% of monthly service fees

Where a covered plan states an uptime commitment at or below 99.0%, any month below that stated commitment but at or above 95.0% earns a 5% credit, and the 10% and 25% bands continue to apply as shown.

5.2 Credit Limitations and Terms

Maximum Credit: 25% of monthly service fees for the affected service
Credit Scope: Credits apply only to the specific service experiencing Downtime
Calculation Base: Credits calculated on monthly recurring fees, excluding setup fees, taxes, and one-time charges
Credit Form: Credits are normally issued as account credit for future services. If the affected service has ended, you have no active paid service, or applicable law requires another remedy, we may provide a refund or other lawful remedy.
Cumulative Limit: Total credits for any monthly period cannot exceed 25% of that month's fees

5.3 Service Credit Request Process

To request service credits:

Submission Deadline: Submit requests via portal.pyro.host or email support@pyro.host within sixty (60) days after the end of the affected month. Requests submitted after this window may be honored at Pyro's discretion; requests not submitted within 60 days are waived. We encourage subscribing to our status page for outage notifications.
Required Information: Include account details, affected service information, and observed Downtime periods
Documentation: Provide error messages, screenshots, or monitoring data when available
Investigation Period: Allow up to fifteen (15) business days for review and credit processing
Verification: Credits granted only after verification through our monitoring systems

5.4 Credit Eligibility Requirements

Service credits are available only when:

You maintained an active, paid affected service during the affected period
The affected service was not suspended for non-payment, policy violations, customer-caused issues, or other exclusions during the Downtime
The Downtime was verified by our monitoring systems or investigation
The request is submitted within the required timeframe
You have complied with all applicable terms, policies, and usage requirements

Unrelated overdue amounts may be offset against approved credits to the extent permitted by law, but unrelated billing issues do not defeat eligibility for an otherwise valid SLA credit unless applicable law permits that result.

6. Scheduled Maintenance

6.1 Maintenance Windows and Notification

Advance Notice: Routine scheduled maintenance that is excluded from Downtime will be announced at least forty-eight (48) hours in advance by email, status page, dashboard, or another reasonable channel where practicable.
Maintenance Frequency: Routine maintenance is generally scheduled during lower-usage periods where practicable.
Duration Limits: We try to keep routine maintenance windows as short as practicable.
Emergency Maintenance: May be performed with shorter notice or no advance notice for security, vendor, reliability, data-protection, or critical infrastructure issues.

6.2 Maintenance Scheduling

Preferred Windows: Maintenance scheduled during lowest traffic periods for your region
Customer Input: Advanced notice allows customers to plan and minimize impact
Coordination: Complex maintenance coordinated across multiple systems to minimize disruption
Rollback Procedures: Prepared rollback plans for maintenance that encounters issues

6.3 Maintenance Exclusions

Scheduled maintenance does not count toward Downtime when:

Advance notice was provided under Section 6.1, except for emergency maintenance described in Section 6.1
Maintenance occurs during the announced time window
Maintenance is completed within the announced window; any portion extending beyond the announced window counts toward Downtime
Procedures follow our standard maintenance protocols

7. Support Response Standards

7.1 Support Availability and Channels

Availability: Ticket submission is available 24/7; tickets are monitored regularly, with responses per Section 7.2
Primary Channel: Submit tickets at portal.pyro.host or email support@pyro.host
Emergency Escalation: Expedited procedures for critical infrastructure issues.
Language Support: English language support with best-effort assistance in other languages.

7.2 Response Time Targets

Issue Severity	Description	Initial Response	Resolution Goal (non-binding)
Critical	Complete service outage	Within 1 hour	4 hours
High	Major functionality impacted	2 hours	24 hours
Medium	Minor functionality affected	8 hours	72 hours
Low	General questions, requests	24 hours	Best effort

Initial Response and Resolution Goal figures are operational targets, not guarantees, unless a specific plan or order states otherwise. Missing a support target does not give rise to service credits. Under Section 14.1, service credits are tied solely to the uptime commitment in Section 3.1 (see Section 5). Initial-response targets are measured during the hours our support team is actively monitoring tickets; outside those hours, response may take longer.

7.3 Severity Level Definitions

Critical: Complete service unavailability affecting primary functionality.
High: Significant service degradation affecting multiple users or core features.
Medium: Limited impact on specific features with workarounds available.
Low: General inquiries, feature requests, or minor issues with minimal impact.

7.4 Support Quality Standards

Support Personnel: Technical support is provided by personnel or contractors with information relevant to the affected service
Escalation Procedures: Internal escalation for complex technical issues
Resolution Tracking: Ticket tracking and follow-up for support requests
Feedback: We may use customer feedback to improve support processes

8. Backup and Data Recovery

8.1 Infrastructure Backup Services

Where backups are included with your plan, we perform automated backups; frequency, retention, and geographic distribution vary by tier and are not guaranteed. We periodically test restoration where feasible.

Backups for services you have elected to host in the EU may be replicated outside the EU under the transfer safeguards described in our Privacy Policy.

Customers remain responsible for maintaining independent backups (Section 8.2), and we do not guarantee the completeness, integrity, or availability of any backup.

8.2 Customer Responsibilities

Independent Backups: Customers are responsible for maintaining their own backup strategies.
Backup Verification: Customers should regularly test the integrity and restorability of their own backups.
Business Continuity: Implementation of appropriate backup policies for business requirements.
Off-Site Storage: Recommended use of multiple backup locations including off-site storage.

8.3 Backup Service Limitations

Best Effort Basis: Backup services provided without absolute guarantees of completeness
Customer Ownership: Primary responsibility for data protection remains with customers
Recovery Time: Backup restoration subject to available resources and may require additional time
Data Integrity: Backup integrity is not guaranteed; customers should maintain their own backup strategy

9. Security and Compliance Standards

9.1 Infrastructure Security Measures

Data Encryption: TLS for Pyro-managed web, API, billing, and control-panel connections where supported, with current production configurations generally using TLS 1.2 or higher; where supported by the service, data at rest is encrypted using industry-standard encryption such as AES-256. For unmanaged services, encryption of data within customer-controlled volumes, databases, applications, game protocols, and other customer-controlled traffic is the customer's responsibility.
Access Controls: We use access controls such as multi-factor authentication and role-based access for administrative systems where applicable.
Monitoring: Automated security monitoring and alerting for selected systems, with human review and escalation where appropriate.
Compliance: Unless a specific service order expressly states otherwise, Pyro is not SOC 2 certified, does not provide a SOC 2 report, and does not certify customer workloads against compliance frameworks.

9.2 Incident Response Procedures

Detection: Automated security monitoring and alerting systems.
Response Time: Automated mitigation of DDoS and volumetric attacks is designed to activate promptly after detection (see Section 4.2). Other security incidents are triaged based on severity, customer impact, legal obligations, available information, and operational capacity.
Communication: Customer notification for incidents affecting their data or services.
Coordination: Collaboration with law enforcement and regulatory bodies when required.
Post-Incident: Post-incident review where appropriate.

9.3 Compliance and Certifications

Data Protection: Controls designed to support our GDPR obligations for EU/UK customers and our CCPA/CPRA obligations for California residents
Security Standards: Information security practices may use recognized frameworks as internal guidance. Unless a specific service order expressly states otherwise, Pyro is not ISO/IEC 27001 certified.
Industry Compliance: Customers remain responsible for determining whether a workload requires regulated hosting or additional controls
Security Reviews: Internal security reviews and vulnerability management periodically; we may engage third parties to assess specific controls

10. Monitoring and Service Information

10.1 Service Monitoring Infrastructure

Service Monitoring: Monitoring of selected service components.
Multiple Locations: Monitoring may use multiple locations where appropriate.
Automated Alerting: Alerting for selected service disruptions.
Operational Logs: Operational logs are retained as needed for service operation, security, troubleshooting, and SLA review.

10.2 Customer Service Information

Status Page: Current status for selected components is available at status.pyro.host where supported
Performance Data: Current status is published at status.pyro.host where practicable; outage and credit information may be provided as part of support or SLA review.
Incident Communications: Service-disruption communications may be provided by email, ticket, dashboard, or status page.
Performance Metrics: Historical performance data may be made available where supported.

10.3 Third-Party Monitoring

Independent Verification: We may use third-party monitoring services to validate availability.
Customer Access: Monitoring data and historical reports may be made available where supported and relevant to an outage or credit request.

11. Geographic and Network Coverage

11.1 Data Center Infrastructure

Primary Locations: Service regions are made available as shown at checkout, in the account dashboard, or in service documentation.
Network Redundancy: Upstream network providers are selected based on availability, cost, performance, and operational needs.
Regional Optimization: Service-region placement is intended to support latency and availability, subject to plan and infrastructure availability.
Expansion Plans: Ongoing evaluation and expansion of geographic coverage.

11.2 Network Performance Optimization

Routing: We route traffic to optimize performance and resilience where available.
Content Delivery: Edge caching and content optimization where supported.
Traffic Engineering: Traffic management for performance where supported.
Peering Relationships: Peering and transit arrangements with reputable Internet providers.

12. SLA Monitoring and Enforcement

12.1 Internal Monitoring Procedures

Automated Systems: Automated monitoring and alerting infrastructure for selected systems.
Manual Verification: Human verification procedures for automated monitoring alerts.
Data Accuracy: Regular calibration and validation of monitoring systems.
Reporting Accuracy: Quality assurance procedures for SLA reporting and calculations.

12.2 Customer Reporting and Feedback

Performance Trends: Historical performance data and trend analysis may be provided on request.
Customer Feedback: Regular collection of customer feedback on service quality and SLA effectiveness.
SLA Review: We may refine SLA commitments based on service performance, customer needs, and operational requirements.

13. SLA Modifications and Updates

13.1 Review and Update Process

Periodic Review: We periodically review SLA commitments and performance.
Performance Analysis: Analysis of actual performance against commitments.
Customer Input: Incorporation of customer feedback and changing requirements.

13.2 Change Notification Process

Advance Notice: Material SLA changes are handled under Section 15.1 of the Terms of Service.
Improvement Implementation: SLA improvements may be implemented immediately.
Customer Rights: Termination rights for material changes are governed by the Terms of Service.
Transition Period: Reasonable transition period for significant SLA modifications.

14. Limitations and Legal Framework

14.1 SLA Remedy Limitations

Except for the carve-outs listed below, service credits are your sole and exclusive remedy for failure to meet the uptime commitment in this SLA, and our liability for such failures is limited to the service credits provided under this agreement.

This limitation does not apply to, and credits are not the exclusive remedy for:

Liability that cannot be excluded or limited under applicable law, including non-waivable consumer rights
Data loss or corruption caused by our gross negligence or willful misconduct
Unauthorized access resulting from our failure to maintain reasonable security
Violations of data-protection law

In those cases, liability is governed by Section 10 of the Terms of Service rather than capped at the service-credit amount. Except as stated here, this Section is subject to, and does not enlarge, the limitations of liability in Section 10 of the Terms of Service.

14.2 External Dependencies

This SLA does not cover performance issues caused by:

Internet service provider problems or routing issues outside our network
Client-side connectivity, hardware, or software problems
Third-party service dependencies or integration failures
Customer network infrastructure or configuration issues

14.3 Force Majeure

SLA commitments may be suspended during force majeure events including natural disasters, war, terrorism, pandemic, epidemics, public health emergencies, cyberattacks, government actions, or other events beyond our reasonable control. We will use reasonable efforts to maintain service continuity and provide timely updates during such events.

15. Contact Information and Support

For SLA-related questions, service credit requests, or performance inquiries:

Primary Support: Submit a ticket at portal.pyro.host
Alternative Contact: support@pyro.host (tickets and emails go to the same support team)
Technical Escalation: Submit a priority ticket at portal.pyro.host or email support@pyro.host (mark urgent)
Status Page: status.pyro.host

Business Address: Pyro Inc.
1604 Philadelphia Pike, Suite 63
Wilmington, DE 19809
United States

Response Target. We review SLA inquiries and service-credit requests as promptly as practicable. Approved credits are applied to the affected account or provided as described in Section 5.2.

This Service Level Agreement sets out our uptime commitment, related service-credit remedy, and operational targets, and is incorporated into our Terms of Service.