We use cookies on our site to analyze traffic, enhance your experience, and provide you with tailored content.

For more information visit our privacy policy.

MTTR Sample Clauses

MTTR. The mean time to repair (MTTR) of a Base Radio Unit shall be a maximum of 30 minutes, excluding travel and access time. This repair time excludes repairs to any cabling to/from the BRU. [***] CONFIDENTIAL TREATMENT REQUESTED 72 39 GXx Xxxxx xx Multipoint Radio Subsystem Specification
Sample 1Sample 2
MTTR. 1) SELLER shall use all commercially reasonable endeavours to maintain the On-Net POP Service Level on Mean Time to Restore (MTTR) within 4 hours. 2) MTTR is calculated by averaging Time-to-Restore (TTR) by number of Network Outage in a month.
Sample 1
MTTR. The Mean Time to Repair (“MTTR”) goal measures the average Time to Repair (“TTR”) within a given month for CenturyLink to restore service after a qualified trouble ticket for a critical or high priority issue has been submitted. A qualified trouble ticket opened by Customer must provide adequate information for CenturyLink to begin the troubleshooting process. If the trouble ticket does not provide enough information for CenturyLink to begin troubleshooting, CenturyLink will attempt to contact the primary Customer contact to obtain the necessary information to complete the trouble ticket. TTR is measured from the time a qualified ticket is opened to the restoration of the affected seat(s). The MTTR goal is calculated by dividing the sum of all the TTR hours in a given month by the number of qualified tickets within the same month. MTTR SLA credits are limited to critical and high priority events. Targets for medium and low priorities and for Communication Points are intended to be informational only. Credit is applied to the MRC of the seats at the affected Customer locations. Any trouble ticket where the service issue is mitigated by use of a temporary solution will be closed once the temporary solution is implemented. A second, lower priority trouble ticket will be created to track further progress toward restoring the original configuration and other associated tasks. Any trouble ticket where the root cause is not found to be on the CenturyLink network or platforms will not count toward SLA calculations, commitments, or credits. MTTR (continued) Priority Description Examples Goal Remedy* Communication Points****
Sample 1Sample 2
MTTR. 5.3.1.1. MTTR is calculated per month, using the following formula: Cumulative Resolve Time of Priority 1 Trouble Tickets per Site, Circuit, or Service during the SCP
Sample 1
MTTR. Rogers offers you with a Mean Time to Repair (“MTTR”) performance objective that measures the duration of time that the Rogers Equipment that connects your Site to the Rogers Wireless Network is Out of Service, as set out in Table 3 below. Such Rogers Equipment encompasses all elements from, and including, the router-modem to the network antenna located at your Site. Customer Premise Equipment (CPE) is not considered as part of the network access. MTTR objectives are based on the location of your Site. MTTR objectives only apply to your Sites that are within one hundred and fifty (150) km (one way) of a Rogers’ Tech Support dispatch location. i) Mean Time to Repair (MTTR) is measured by calculating the average length of time it took to respond to and implement a repair for your particular access issue during a specific month. The MTTR is an objective only and Rogers will use commercially reasonable efforts to meet the objective. Rogers is not liable for any failure to meet the MTTR objective and you do not have a right to terminate as a result of Rogers’ failure to the meet the MTTR objective. MTTR metrics are measured solely against Out of Service conditions on the applicable Rogers Equipment. MTTR metrics are based solely on Out of Service statistics collected by the Rogers Trouble Reporting System (TRS), and exclude the following: a) an event of Force Majeure or other event beyond the reasonable control of Rogers; b) the Services are not available, or your end-user devices are unable to transmit data traffic due to the failure, malfunction or (including, without limitation, any applications or software thereon) or any other applications, systems or equipment not owned or controlled by Rogers including, without limitation, your Internet Service Provider connections; c) your individual end-user devices are unable to transmit and/or receive data due to reasons other than a Rogers Wireless Network outage affecting the Services; or d) the Rogers Wireless Network was unavailable due to planned, routine or emergency maintenance. e) The above service level objectives do not apply to the Services with unlimited usage plans.
Sample 1
MTTR. ‌ The MTTR (mean time to repair) refers to the time the Provider requires to replace defective hardware with functioning hardware. To measure the service level, the Provider documents the point in time when the downtime occurs and the point in time when the system is up and running again. When troubleshooting has been completed and any hardware problem has been repaired and the server has been restarted, the Provider informs the Customer and closes the service ticket. This action defines the end of the measured time period. The time the server requires to boot the operating system, reinstall any software or restore backup data is not included in the measurement of the service level.
Sample 1
MTTR. Rogers offers the Customer with a Mean Time to Repair (“MTTR”) performance objective that measures the duration of time that the Rogers Equipment that connects a Customer Site to the Rogers Wireless Network is Out of Service, as set out in Table 2 below. Such Rogers Equipment encompasses all elements from, and including, the router-modem to the network antenna located at the Customer Site. Customer Premise Equipment (CPE) is not considered as part of the network access. MTTR objectives are based on the location of the Customer’s Site. MTTR objectives only apply to Customer Sites that are within one hundred and fifty (150) km (one way) of a Rogers’ Tech Support dispatch location.
Sample 1

Related to MTTR

  • Downtime Each of Zero Hash and ZHLS uses commercially reasonable efforts to provide the Services in a reliable and secure manner. From time to time, interruptions, errors, delays, or other deficiencies in providing the Services may occur due to a variety of factors, some of which are outside of Zero Hash’s and/or ZHLS’ control, and some which may require or result in scheduled maintenance or unscheduled downtime of the Services (collectively, “Downtime”). You understand and acknowledge that part or all of the Services may be unavailable during any such period of Downtime, and you acknowledge that Zero Hash and ZHLS are not liable or responsible to you for any inconvenience or losses to you as a result of Downtime. Following Downtime, you further understand and acknowledge that the prevailing market prices of cryptocurrency may differ significantly from the prices prior to such Downtime.

  • Geometric visibility The visibility of the illuminating surface, including its visibility in areas which do not appear to be illuminated in the direction of observation considered, shall be ensured within a divergent space defined by generating lines based on the perimeter of the illuminating surface and forming an angle of not less than 5° with the axis of reference of the headlamp.

  • Traffic Measurement and Billing over Interconnection Trunks 6.1 For billing purposes, each Party shall pass Calling Party Number (CPN) information on at least ninety-five percent (95%) of calls carried over the Interconnection Trunks. 6.1.1 As used in this Section 6, “Traffic Rate” means the applicable Reciprocal Compensation Traffic rate, Measured Internet Traffic rate, intrastate Switched Exchange Access Service rate, interstate Switched Exchange Access Service rate, or intrastate/interstate Tandem Transit Traffic rate, as provided in the Pricing Attachment, an applicable Tariff, or, for Measured Internet Traffic, the FCC Internet Order. 6.1.2 If the originating Party passes CPN on ninety-five percent (95%) or more of its calls, the receiving Party shall xxxx the originating Party the Traffic Rate applicable to each relevant minute of traffic for which CPN is passed. For any remaining (up to 5%) calls without CPN information, the receiving Party shall xxxx the originating Party for such traffic at the Traffic Rate applicable to each relevant minute of traffic, in direct proportion to the minutes of use of calls passed with CPN information. 6.1.3 If the originating Party passes CPN on less than ninety-five percent (95%) of its calls and the originating Party chooses to combine Reciprocal Compensation Traffic and Toll Traffic on the same trunk group, the receiving Party shall xxxx the higher of its interstate Switched Exchange Access Service rates or its intrastate Switched Exchange Access Services rates for all traffic that is passed without CPN, unless the Parties agree that other rates should apply to such traffic. 6.2 At such time as a receiving Party has the capability, on an automated basis, to use such CPN to classify traffic delivered over Interconnection Trunks by the other Party by Traffic Rate type (e.g., Reciprocal Compensation Traffic/Measured Internet Traffic, intrastate Switched Exchange Access Service, interstate Switched Exchange Access Service, or intrastate/interstate Tandem Transit Traffic), such receiving Party shall xxxx the originating Party the Traffic Rate applicable to each relevant minute of traffic for which CPN is passed. If the receiving Party lacks the capability, on an automated basis, to use CPN information on an automated basis to classify traffic delivered by the other Party by Traffic Rate type, the originating Party will supply Traffic Factor 1 and Traffic Factor

  • Connectivity User is solely responsible for providing and maintaining all necessary electronic communications with Exchange, including, wiring, computer hardware, software, communication line access, and networking devices.

  • Start-Up and Synchronization Consistent with the mutually acceptable procedures of the Developer and Connecting Transmission Owner, the Developer is responsible for the proper synchronization of the Large Generating Facility to the New York State Transmission System in accordance with NYISO and Connecting Transmission Owner procedures and requirements.

  • Help Desk A help desk for Product support issues (the “Help Desk”) will be available to Customer. Unless specified in an Order, Customer should contact 000.000.0000 to receive a telephone number for the applicable supporting Solutions & Support Center. Customer will appoint one Product administrator and one backup administrator to serve as the primary point of contact regarding maintenance services.

  • Infrastructure Vulnerability Scanning Supplier will scan its internal environments (e.g., servers, network devices, etc.) related to Deliverables monthly and external environments related to Deliverables weekly. Supplier will have a defined process to address any findings but will ensure that any high-risk vulnerabilities are addressed within 30 days.

  • Interconnection Customer (1) Interconnection Customer shall construct and, unless otherwise indicated, shall own, the following Interconnection Facilities: None (2) In the event that, in accordance with the Interconnection Construction Service Agreement, Interconnection Customer has exercised the Option to Build, it is hereby permitted to build in accordance with and subject to the conditions and limitations set forth in that Section, the following portions of the Transmission Owner Interconnection Facilities which constitute or are part of the Customer Facility: None Ownership of the facilities built by Interconnection Customer pursuant to the Option to Build shall be as provided in the Interconnection Construction Service Agreement.

  • One-Way Interconnection Trunks 2.3.1 Where the Parties use One-Way Interconnection Trunks for the delivery of traffic from Onvoy to Frontier, Onvoy, at Onvoy’s own expense, shall: 2.3.1.1 provide its own facilities for delivery of the traffic to the technically feasible Point(s) of Interconnection on Frontier’s network in a LATA; and/or 2.3.1.2 obtain transport for delivery of the traffic to the technically feasible Point(s) of Interconnection on Frontier’s network in a LATA (a) from a third party, or, (b) if Frontier offers such transport pursuant to a Frontier access Tariff, from Frontier. 2.3.2 For each Tandem or End Office One-Way Interconnection Trunk group for delivery of traffic from Onvoy to Frontier with a utilization level of less than sixty percent (60%) for final trunk groups and eighty-five percent (85%) for high usage trunk groups, unless the Parties agree otherwise, Onvoy will promptly submit ASRs to disconnect a sufficient number of Interconnection Trunks to attain a utilization level of approximately sixty percent (60%) for all final trunk groups and eighty-five percent (85%) for all high usage trunk groups. In the event Onvoy fails to submit an ASR to disconnect One-Way Interconnection Trunks as required by this Section, Frontier may disconnect the excess Interconnection Trunks or bill (and Onvoy shall pay) for the excess Interconnection Trunks at the rates set forth in the Pricing Attachment. 2.3.3 Where the Parties use One-Way Interconnection Trunks for the delivery of traffic from Frontier to Onvoy, Frontier, at Frontier’s own expense, shall provide its own facilities for delivery of the traffic to the technically feasible Point(s) of Interconnection on Frontier’s network in a LATA.

  • Interconnection Customer Authority Consistent with Good Utility Practice, this LGIA, and the CAISO Tariff, the Interconnection Customer may take actions or inactions with regard to the Large Generating Facility or the Interconnection Customer’s Interconnection Facilities during an Emergency Condition in order to (i) preserve public health and safety, (ii) preserve the reliability of the Large Generating Facility or the Interconnection Customer’s Interconnection Facilities,

Most Referenced Clauses

Most Referenced Definitions