Incident Response & Support Services

GateLLM is a fully self-hosted product: the gateway process runs within infrastructure (VPC / on-premises data center) owned or controlled by you (the Controller). Fluxon LLC ("Processor") does not host runtime instances. Therefore, this document does not provide SaaS-style runtime availability percentage commitments or service-credit compensation — that would misleadingly imply "this is a SaaS," conflicting with the core positioning of "data never leaves your network, you are in control."

What this document clarifies: under the fully self-hosted deployment model, the Processor's response commitments for software defect remediation, security incident response, and License Service maintenance, as well as support service tiers. Runtime instance high availability is determined by your deployment architecture; we provide deployment guidance (Section 4). The incident response process (Section 5) is the core basis for procurement to assess "who to contact when something goes wrong, and how fast they respond."

To avoid misplaced responsibility, the following boundaries are clarified:

• Processor is responsible for: defect remediation and version releases of the GateLLM software itself; security vulnerability response and remediation (see the Vulnerability Disclosure Policy); operation and maintenance of the License Service; support service response.
• Controller is responsible for: deployment and operations of runtime instances (replica count, cross-AZ, health checks, automatic failover); availability of its own infrastructure (network, VPC, compute resources); availability of downstream model provider services (GateLLM's cross-provider fallback has attempted mitigation).
• Runtime availability: determined by your deployment architecture, not guaranteed by the Processor. The Processor provides Helm Charts and deployment best-practice guidance to help you achieve high availability (Section 4), but does not back a runtime-instance availability percentage.

The License Service validates license validity when a GateLLM instance starts. The Processor may perform planned maintenance on this service, with the following terms:

• Advance notice: at least 72 hours via the email registered in your account
• Maintenance window: scheduled during off-peak hours (02:00-06:00 UTC)
• Maintenance duration: no more than 2 hours per session, no more than 4 hours cumulatively per month
• No business impact during maintenance: GateLLM instances continue to operate based on a locally cached license for a grace period (default 14 days); the gateway process functions normally during planned maintenance without service interruption

The high availability of the GateLLM gateway process itself is determined by your deployment architecture. We recommend the following deployment practices to maximize runtime availability:

• Multi-replica deployment: deploy ≥ 2 gateway replicas via the Helm Chart, with a load balancer distributing traffic
• Cross-AZ: distribute replicas across different availability zones (AZs) to withstand single-AZ failures
• Health checks & auto-restart: configure Kubernetes liveness/readiness probes so failed replicas are automatically restarted and drained
• Stateless design: the gateway process holds no session state (keys are loaded from configuration into memory), so any replica can serve any request, enabling horizontal scaling and instant failover
• Cross-provider fallback: GateLLM's built-in cross-provider fallback mechanism automatically switches when a downstream model provider is down, ensuring model-call availability at the architecture level
• Local caching & grace periods: license local-cache grace, configuration local cache, reducing real-time dependence on external dependencies

Security whitepaper & architecture

The Processor maintains the following incident response process, applicable to events affecting the security, stability, or License Service of the GateLLM software. Incidents are classified by severity and responded to within the corresponding timeframes:

Incidents are classified into four levels:

• P1 Critical: an actively exploited security vulnerability in the GateLLM software affecting production data, or a critical software defect rendering it unusable with no workaround. Response: acknowledged within 15 minutes; mitigated within 4 hours.
• P2 High: a high-severity security vulnerability is discovered, or a software defect affecting core functionality. Response: acknowledged within 1 hour; mitigated within 8 hours.
• P3 Medium: localized functional issues with workarounds, or a medium-severity security vulnerability. Response: acknowledged within 4 hours; mitigated within 1 business day.
• P4 Low: minor issues not affecting core functionality, or low-severity security vulnerabilities. Response: acknowledged within 1 business day; fixed per the vulnerability disclosure policy timeline.

Incident notification mechanism:

• Notification channels: the email registered in the Controller's account; P1/P2 incidents additionally trigger a phone call (if an emergency contact is registered)
• Initial notification: sent within 30 minutes of incident confirmation, including an incident summary, impact scope, and initial mitigation measures
• Progress updates: P1 every 2 hours, P2 every 4 hours, P3 every 1 business day, until resolved
• Security incident unified entry: security@gatellm.io, response per the vulnerability disclosure policy

Incident handling follows a standard process:

• Detection & confirmation: triggered by monitoring alerts or customer reports; the on-call engineer confirms the incident and assigns a severity
• Mitigation: prioritize stopping the bleeding, possibly using temporary measures (e.g., providing workarounds, releasing hotfixes)
• Root Cause Analysis (RCA): after mitigation, deeply identify the root cause
• Remediation: develop and release a formal fixed version
• Post-mortem: for P1/P2 incidents, a post-incident report is produced within 5 business days of resolution, including the timeline, root cause, impact, improvement measures, and follow-up items
• Improvement tracking: improvement items identified in the post-mortem are tracked, and progress is periodically communicated to affected customers

Vulnerability Disclosure Policy

Response levels for support services:

• Enterprise: 7×24 critical-incident (P1/P2) support; P1 15-minute, P2 1-hour response; dedicated Technical Account Manager (TAM); quarterly architecture reviews
• Pro: business-hours (9×5) support; P1/P2 1-hour response (during business hours)
• Free: community support (documentation + community forum), no guaranteed response time
• Security incidents: all tiers may report via security@gatellm.io, responded to per the vulnerability disclosure policy

Support & incident reports: support@gatellm.io. Security incidents: security@gatellm.io. Commercial inquiries: contact your dedicated account manager or support@gatellm.io.

Data Processing Agreement (DPA) · Vulnerability Disclosure Policy · Security & Compliance