SLA and uptime tracking in Rest API - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define the endpoint path for uptime status.

Rest API

GET /api/[1]/status

Drag options to blanks, or click blank then click option'

Auptime

Bhealth

Cmetrics

Dlogs

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'health' instead of 'uptime' which is more general.

Using 'logs' which is unrelated to uptime status.

The endpoint path for checking uptime is usually '/uptime'.

2fill in blank

medium

Complete the code to specify the HTTP method for retrieving SLA data.

Rest API

[1] /api/sla/data

Drag options to blanks, or click blank then click option'

APOST

BGET

CPUT

DDELETE

Attempts:

3 left

💡 Hint

Common Mistakes

Using POST which is for sending data.

Using DELETE which removes data.

GET method is used to retrieve data without modifying it.

3fill in blank

hard

Fix the error in the JSON response key for uptime percentage.

Rest API

{
  "uptime_[1]": 99.95
}

Drag options to blanks, or click blank then click option'

Apercentile

Bpercent

Cpercentage

Dpercentages

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'percent' which is less descriptive.

Using 'percentile' which is a statistical term.

The correct key name is 'uptime_percentage' to clearly indicate the value.

4fill in blank

hard

Fill both blanks to filter SLA records by minimum uptime and sort order.

Rest API

GET /api/sla/records?min_uptime=[1]&sort=[2]

Drag options to blanks, or click blank then click option'

A99.9

Bdesc

Casc

D100

Attempts:

3 left

💡 Hint

Common Mistakes

Using 100 as minimum uptime which is too strict.

Using 'desc' when ascending order is expected.

We filter records with minimum uptime 99.9 and sort them in ascending order.

5fill in blank

hard

Fill all three blanks to create a JSON payload for updating SLA thresholds.

Rest API

{
  "[1]": [2],
  "[3]": 99.99
}

Drag options to blanks, or click blank then click option'

Amin_uptime

Bthreshold

Cmax_downtime

D100

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing 'threshold' with key names.

Using wrong numeric values.

The payload sets 'min_uptime' to 100 and 'max_downtime' to 99.99.

Practice

1. What does SLA stand for in the context of uptime tracking?

easy

A. Service Level Agreement

B. System Log Analysis

C. Server Load Average

D. Standard Latency Assessment

Solution

1. Step 1: Understand SLA meaning

   SLA is a contract that defines expected service performance and uptime.

2. Step 2: Match SLA to options

   Only "Service Level Agreement" correctly describes this contract.

3. Final Answer:

   Service Level Agreement -> Option A

4. Quick Check:

   SLA = Service Level Agreement [OK]

Hint: Remember SLA means agreement on service quality [OK]

Common Mistakes:

• Confusing SLA with system logs
• Thinking SLA measures latency
• Mixing SLA with server load

2. Which HTTP method is typically used to retrieve uptime data from a REST API?

easy

A. POST

B. DELETE

C. PUT

D. GET

Solution

1. Step 1: Identify REST API methods for data retrieval

   GET method is used to request data without changing server state.

2. Step 2: Match method to uptime data retrieval

   Since uptime data is fetched, GET is the correct method.

3. Final Answer:

   GET -> Option D

4. Quick Check:

   Retrieve data with GET [OK]

Hint: Use GET to fetch data from REST APIs [OK]

Common Mistakes:

• Using POST to fetch data
• Confusing DELETE with retrieval
• Using PUT for reading data

3. Given this JSON response from an uptime API:

{"uptime_percentage": 99.5, "downtime_minutes": 30}

What is the actual uptime in minutes if the total period is 1440 minutes (1 day)?

medium

A. 1440 minutes

B. 1395 minutes

C. 1410 minutes

D. 1430 minutes

Solution

1. Step 1: Calculate uptime from total and downtime

   Uptime = Total minutes - Downtime minutes = 1440 - 30 = 1410 minutes.

2. Step 2: Confirm with options

   1410 minutes matches 1410 minutes. The percentage is a separate metric.

3. Final Answer:

   1410 minutes -> Option C

4. Quick Check:

   Uptime = 1440 - 30 = 1410 [OK]

Hint: Subtract downtime from total time for uptime [OK]

Common Mistakes:

• Using downtime as uptime
• Ignoring total period
• Confusing percentage with minutes

4. You have this REST API call to get uptime:

import requests
response = requests.get('https://api.example.com/uptime')
data = response.json()
uptime = data['up_time_percentage']

What is the error in this code?

medium

A. Incorrect key name 'up_time_percentage' instead of 'uptime_percentage'

B. Missing import for requests module

C. Using GET instead of POST method

D. No error, code is correct

Solution

1. Step 1: Check JSON key names

   The API returns key 'uptime_percentage', but code uses 'up_time_percentage'.

2. Step 2: Identify key mismatch error

   This causes a KeyError because the key name is incorrect.

3. Final Answer:

   Incorrect key name 'up_time_percentage' instead of 'uptime_percentage' -> Option A

4. Quick Check:

   Key name must match JSON exactly [OK]

Hint: Match JSON keys exactly to avoid errors [OK]

Common Mistakes:

• Typos in key names
• Using wrong HTTP method
• Forgetting to import requests

5. You want to check if a service meets its SLA of 99.9% uptime over a month (43200 minutes). The API returns:

{"uptime_percentage": 99.85}

Which statement correctly describes the SLA status?

hard

A. Service meets SLA because uptime is above 99.8%.

B. Service fails SLA because uptime is below 99.9%.

C. Service meets SLA because downtime is less than 60 minutes.

D. Service fails SLA because uptime percentage is not provided.

Solution

1. Step 1: Compare reported uptime to SLA target

   The SLA requires at least 99.9%, but actual uptime is 99.85%, which is less.

2. Step 2: Determine SLA compliance

   Since 99.85% < 99.9%, the service fails the SLA.

3. Final Answer:

   Service fails SLA because uptime is below 99.9% -> Option B

4. Quick Check:

   Actual uptime < SLA target means failure [OK]

Hint: Compare actual uptime directly to SLA percentage [OK]

Common Mistakes:

• Assuming close enough meets SLA
• Ignoring SLA threshold
• Confusing downtime with uptime