Bird
Raised Fist0
Rest APIprogramming~30 mins

API monitoring and alerting in Rest API - Mini Project: Build & Apply

Choose your learning style10 modes available
API Monitoring and Alerting
📖 Scenario: You work as a DevOps engineer responsible for keeping an important web API running smoothly. Your team wants to monitor the API's response times and get alerts if it becomes slow.Imagine you have a simple script that checks the API response time and alerts if it is too high.
🎯 Goal: Build a simple API monitoring script that stores response times, sets a threshold for slow responses, checks the response times against the threshold, and prints alerts for slow responses.
📋 What You'll Learn
Create a list of API response times in milliseconds
Add a threshold variable for slow response time
Write a loop to find response times above the threshold
Print alerts for each slow response time
💡 Why This Matters
🌍 Real World
Monitoring API response times helps keep web services reliable and fast for users.
💼 Career
DevOps engineers often write scripts like this to automate monitoring and alerting for system health.
Progress0 / 4 steps
1
Create a list of API response times
Create a list called response_times with these exact values: 120, 250, 180, 300, 90
Rest API
Hint

Use square brackets to create a list and separate numbers with commas.

2
Set a threshold for slow response time
Create a variable called threshold and set it to 200 to represent the maximum acceptable response time in milliseconds.
Rest API
Hint

Use a simple assignment statement to create the variable.

3
Find slow response times
Use a for loop with the variable time to iterate over response_times. Inside the loop, use an if statement to check if time is greater than threshold. If yes, add time to a new list called slow_responses.
Rest API
Hint

Remember to create the empty list slow_responses before the loop.

4
Print alerts for slow responses
Use a for loop with the variable slow_time to iterate over slow_responses. Inside the loop, print the message: "Alert: Slow response time detected - X ms" where X is the value of slow_time.
Rest API
Hint

Use an f-string inside the print statement to include the variable value.

Practice

(1/5)
1. What is the main purpose of API monitoring in DevOps?
easy
A. To design the API user interface
B. To write new API endpoints
C. To regularly check if the API is working correctly
D. To store API data permanently

Solution

  1. Step 1: Understand API monitoring

    API monitoring means checking the API often to see if it works well without errors.
  2. Step 2: Identify the main goal

    The main goal is to ensure the API is available and responds correctly to requests.
  3. Final Answer:

    To regularly check if the API is working correctly -> Option C
  4. Quick Check:

    API monitoring = regular checks [OK]
Hint: Monitoring means checking often if API works [OK]
Common Mistakes:
  • Confusing monitoring with API design
  • Thinking monitoring stores data
  • Mixing monitoring with coding new endpoints
2. Which of the following is the correct way to set up an alert for API downtime in a monitoring tool?
easy
A. Trigger alert if API response time is less than 100ms
B. Trigger alert if API documentation changes
C. Trigger alert if API returns status code 200
D. Trigger alert if API returns status code 500 or no response

Solution

  1. Step 1: Understand alert conditions for downtime

    An alert for downtime should trigger when the API fails or does not respond, such as status code 500 or no response.
  2. Step 2: Evaluate options

    Trigger alert if API returns status code 500 or no response correctly triggers alert on error or no response. Other options either alert on success or unrelated events.
  3. Final Answer:

    Trigger alert if API returns status code 500 or no response -> Option D
  4. Quick Check:

    Alert on errors or no response = Trigger alert if API returns status code 500 or no response [OK]
Hint: Alert on errors or no response, not success [OK]
Common Mistakes:
  • Alerting on successful responses
  • Alerting on unrelated changes like docs
  • Using wrong status codes for alerts
3. Given this monitoring script snippet:
response = requests.get('https://api.example.com/data')
if response.status_code != 200:
    send_alert('API error detected')

What happens if the API returns status code 404?
medium
A. No alert is sent
B. An alert is sent with message 'API error detected'
C. The script crashes with an error
D. The script retries the request automatically

Solution

  1. Step 1: Analyze the condition in the script

    The script sends an alert if the status code is not 200.
  2. Step 2: Check the status code 404

    Since 404 is not 200, the condition is true and alert is sent.
  3. Final Answer:

    An alert is sent with message 'API error detected' -> Option B
  4. Quick Check:

    Status code 404 triggers alert [OK]
Hint: Alert triggers if status code not 200 [OK]
Common Mistakes:
  • Thinking 404 is success
  • Assuming script crashes on 404
  • Believing script retries automatically
4. You wrote this alert rule:
if response.status_code = 500:
    send_alert('Server error')

Why does this rule not work as expected?
medium
A. The comparison operator should be '==' not '='
B. The status code 500 is not an error
C. send_alert function is missing parentheses
D. The API URL is missing

Solution

  1. Step 1: Identify the operator used

    The code uses '=' which is assignment, not comparison.
  2. Step 2: Correct operator for comparison

    To compare values, '==' must be used instead of '='.
  3. Final Answer:

    The comparison operator should be '==' not '=' -> Option A
  4. Quick Check:

    Use '==' for comparison [OK]
Hint: Use '==' to compare values, '=' assigns [OK]
Common Mistakes:
  • Using '=' instead of '==' in conditions
  • Thinking 500 is not an error
  • Ignoring syntax errors in conditions
5. You want to monitor an API that sometimes returns status 429 (too many requests) temporarily. Which alerting strategy best avoids false alarms?
hard
A. Alert only if 429 responses occur continuously for 5 minutes
B. Alert immediately on any 429 response
C. Ignore 429 responses completely
D. Alert only if 429 responses are followed by 200 responses

Solution

  1. Step 1: Understand 429 status meaning

    Status 429 means too many requests temporarily; it may resolve quickly.
  2. Step 2: Choose alerting strategy to avoid false alarms

    Alerting immediately on one 429 may cause false alarms; waiting for continuous 429s for 5 minutes reduces noise.
  3. Final Answer:

    Alert only if 429 responses occur continuously for 5 minutes -> Option A
  4. Quick Check:

    Delay alerts on temporary errors to reduce false alarms [OK]
Hint: Wait before alerting on temporary errors [OK]
Common Mistakes:
  • Alerting immediately on every 429
  • Ignoring 429 which may hide real issues
  • Alerting on 429 followed by success
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard