1. Scope of This Agreement

This SLA applies only to the paid recurring CORE-hosted components identified as covered in an accepted order, such as a managed web application, compute service, or database. A one-time deliverable, free or trial service, third-party system, carrier delivery path, client-owned integration, or component excluded by the order is not covered.

Domain registrations, transfers, renewals, WHOIS/RDAP publication, registry processing, premium-name pricing, seller negotiations, escrow handling, and domain broker outcomes are not covered by uptime or service-credit commitments except where a written agreement expressly says otherwise.

This SLA is incorporated into the applicable order and Terms of Service. A signed order or plan-specific SLA controls its expressly negotiated coverage, target, measurement, support window, credit, and exclusion; the Terms govern matters the specific document does not change.

2. Service Availability

The accepted order or current administrator-published plan identifies any monthly availability target, covered CORE-controlled production boundary, monitoring endpoint, and remedy. A catalog example or historical target does not override that current configuration.

The same controlling plan identifies any service-credit thresholds, percentages, cap, evidence, and claim window. No credit is due when the measured service meets the applicable target or the order does not include a credit commitment.

Unless the plan states another formula, monthly availability compares covered minutes with verified downtime minutes at the configured service boundary. The monitoring interval and consecutive-failure threshold determine when downtime starts and ends. Partial degradation is handled under the plan's incident and measurement rules rather than automatically counted as total unavailability.

3. Support Response & Resolution Times

CORE provides support through the client portal, email, and live chat when available. The support hours and targets shown in the accepted order, portal, or current administrator-approved support settings apply to the account and may vary by plan.

A response target measures acknowledgement and the start of triage, not a guaranteed resolution. Priority is assigned from the affected users, production impact, security or legal risk, available workaround, and whether the cause is within CORE's control.

Response times are measured from when a support ticket is opened in the client portal or when an email is received at a CORE support address during the applicable support window. Reports submitted outside that window begin measurement when the window reopens unless the accepted order includes after-hours coverage.

4. Scheduled Maintenance

CORE performs scheduled maintenance to keep infrastructure secure and current. When practical, CORE announces material planned interruption through the configured account channel or portal using the notice window stated in the applicable order. Emergency security, abuse, or reliability work may occur sooner when delay would create unreasonable risk.

Maintenance is excluded from availability only to the extent the controlling plan permits and the interruption remains within the announced or reasonably necessary emergency scope. Labeling an unrelated outage as maintenance does not exclude it.

5. Incident Communication

For a confirmed material incident, CORE records the event and uses the configured status, portal, ticket, email, or escalation channel appropriate to its scope. Detection time, confirmation time, and notice time can differ while alerts are investigated and duplicate failures are consolidated.

CORE provides updates and, when warranted by scope or the accepted order, a post-incident summary on a reasonable cadence based on severity, available facts, recovery work, and security constraints. CORE may withhold exploit details or unverified findings that would create additional risk.

6. Service Credits

To request a service credit, use the portal or email legal@coretv.co within the claim window shown in the controlling plan and identify the covered service, incident, date, and available impact evidence.

Approved credits apply as stated in the plan, ordinarily against a future invoice for the affected service. They are not cash and do not exceed the plan's cap. Credits are the contractual remedy for an eligible availability shortfall unless a signed agreement or non-waivable law provides another remedy.

An exclusion applies only to the extent a client action, unsupported configuration, force majeure event, planned maintenance, provider dependency, nonpayment suspension, or AUP violation identified in the plan caused the measured shortfall. A third-party label does not exclude downtime attributable to CORE's covered integration, configuration, or conduct.

7. Exclusions & Exceptions

Potential exclusions include force majeure, third-party Internet routing, DNS propagation, a DDoS attack outside the promised mitigation boundary, properly scoped maintenance, client-requested changes, client-managed misconfiguration, lawful suspension, and registry, registrar, escrow, marketplace, registrant, or other independent transfer delay. An exclusion applies only when stated by the controlling plan and only to the extent it caused the shortfall.

Brokered domain acquisitions are best-effort professional services. CORE does not guarantee owner response times, seller acceptance, negotiated price, escrow timeline, registrar approval, registry approval, or successful transfer.

8. Third-Party AI & Voice Provider Downtime

CORE services may route a configured function to an independent AI, transcription, speech, telephony, messaging, email, or search provider. The enabled provider can vary by feature and project and operates infrastructure outside CORE's direct control.

A provider-originated interruption is excluded from the uptime calculation only to the extent the applicable order assigns that dependency outside the covered service and the provider event caused the shortfall. An outage in CORE-controlled integration logic, configuration, routing, or a promised redundancy measure remains evaluated under the coverage stated in the order.

Where commercially reasonable and technically feasible, CORE may fail over to an alternative provider or use another mitigation. No failover is guaranteed unless the accepted order says otherwise. CORE remains responsible for its own contractual obligations while independent providers remain responsible for theirs.

9. Measurement Methodology

CORE measures uptime from the health checks and incident records configured for the applicable project. The current platform ordinarily schedules HTTP health checks approximately every five minutes, but a project order or administrator-approved monitoring configuration may specify a different interval, endpoint, or provider. An isolated failed probe is investigated and does not by itself establish billable downtime.

Clients may use independent third-party monitoring services to provide evidence of an outage. CORE reviews its monitoring records together with credible client evidence in good faith; the applicable order, monitoring configuration, exclusions, and service-credit rules control the final calculation.

10. Changes to This SLA

CORE may revise this general SLA prospectively. A change does not silently reduce a service level fixed in an active signed order; the order's amendment, renewal, and notice terms control. For other material changes, CORE provides the advance notice required by the agreement or applicable law.

For questions about this SLA: legal@coretv.co.

---

11. Covered platform & automation components

Unless an order expressly says otherwise, the uptime target applies to the CORE-hosted production web service measured at CORE's service boundary. It does not guarantee that every third-party carrier, mailbox, registrar, payment network, AI model, analytics provider, integration, client-owned account, or recipient device will be continuously available.

AI responses, call transfer, transcription, email/SMS delivery, workflow execution, estimates, recommendations, and scheduled follow-ups depend on third-party and queued services. CORE monitors supported components and uses retries, escalation, or a human fallback where configured, but does not guarantee response accuracy, carrier delivery, inbox placement, transfer completion, booking attendance, or execution at an exact second.

A delivery blueprint, readiness state, interactive timeline, dependency graph, proposal activity signal, universal-search result, or service-health score may help coordinate work, but it is not an uptime measurement, guaranteed completion date, staffing commitment, or promised business result. Only the accepted order and the covered measurement method create a service-level commitment.

12. Incident priority, response & escalation

Support targets measure the time to acknowledge and begin triage during the applicable support window; they are not guaranteed resolution times. Priority considers affected users, security or legal risk, production impact, available workaround, and whether the issue is inside CORE's control. Duplicate reports may be consolidated under one incident.

Critical communication or automation failures may create a high-priority ticket and notify an on-call contact. An attempted transfer, callback, escalation, or notification is not a guarantee that a particular person will answer. If no on-call person accepts an after-hours escalation, CORE may preserve the record and schedule the next available follow-up.

13. Operational scorecards & SLA measurement

Client-success, service-health, risk, relationship, or recommended-action indicators are operational aids built from available project, support, satisfaction, request, and billing records. They can be delayed, incomplete, or incorrect and do not define uptime, downtime, incident priority, a service credit, or breach of this SLA.

Only the covered endpoint, measurement source, support window, incident record, calculation method, exclusions, and credit schedule stated in the applicable order or current plan determine an SLA result. An operational score cannot silently reduce those commitments or a non-waivable remedy.

14. Client actions, exclusions & service credits

The client must maintain supported configurations, valid credentials and payment, required provider registrations, accurate DNS, lawful content, reasonable traffic patterns, and timely access or approvals. Delays, failures, or security events caused by client instructions, unauthorized changes, unsupported integrations, force majeure, planned maintenance, provider suspension, or violations of the Acceptable Use Policy are excluded to the extent stated in the applicable order.

A request rejected by a correctly operating, reasonably configured rate limit, IP or network deny rule, disposable-email control, authentication requirement, or abuse safeguard is not downtime. A widespread defect that prevents eligible users from reaching the service or the published review channel remains subject to the ordinary covered-service measurement and incident process; labeling a defect as a security control does not remove a commitment that the accepted order or non-waivable law makes applicable.

Any service credit is calculated only under the published measurement method and must be requested within the stated claim window. Credits are the contractual remedy for an eligible availability shortfall unless non-waivable law or a signed agreement provides otherwise; they are not cash refunds and do not cover indirect loss.