API monitoring and alerting in Rest API - Step-by-Step Execution

Concept Flow - API monitoring and alerting

Start Monitoring Setup

↓

Define API Endpoint

↓

Set Monitoring Frequency

↓

Send API Request

↓

Check Response Status

↓

Log Success

↓

Wait Interval

↓

Repeat

This flow shows how API monitoring sends requests regularly, checks responses, logs success or triggers alerts on errors, then repeats.

Execution Sample

Rest API

1. Define API endpoint: https://api.example.com/data
2. Set frequency: every 60 seconds
3. Send GET request
4. Check if status code == 200
5. If not, send alert notification

This code monitors an API by sending a GET request every minute and alerts if the response is not successful.

Execution Table

Step	Action	Request Sent	Response Status	Alert Triggered	Log Entry
1	Send GET request to API	GET https://api.example.com/data	200 OK	No	Success logged
2	Wait 60 seconds	No request	No response	No	No log
3	Send GET request to API	GET https://api.example.com/data	500 Internal Server Error	Yes	Error logged
4	Send alert notification	No request	No response	Yes	Alert sent to team
5	Wait 60 seconds	No request	No response	No	No log
6	Send GET request to API	GET https://api.example.com/data	200 OK	No	Success logged
7	End monitoring session	No request	No response	No	Monitoring stopped

💡 Monitoring stopped manually after step 7

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	After Step 6	Final
Response Status	None	200 OK	500 Internal Server Error	500 Internal Server Error	200 OK	200 OK
Alert Triggered	False	False	True	True	False	False
Log Entry	None	Success logged	Error logged	Alert sent to team	Success logged	Success logged

Key Moments - 3 Insights

Why does the alert trigger only on some steps and not every time?

The alert triggers only when the response status is an error (like 500), as shown in execution_table step 3 and 4. Successful responses (200 OK) do not trigger alerts.

What happens during the wait steps in monitoring?

During wait steps (like step 2 and 5), no requests are sent and no logs or alerts occur. This pause controls the monitoring frequency.

How does the system know when to stop monitoring?

Monitoring stops manually or by a condition outside this flow, as indicated in step 7 with no further requests sent.

Visual Quiz - 3 Questions

Look at the execution table, what is the Response Status at Step 3?

A 200 OK

B 404 Not Found

C 500 Internal Server Error

D No response

💡 Hint

Check the 'Response Status' column in the execution_table row for Step 3.

At which step does the alert get sent to the team?

A Step 1

B Step 4

C Step 6

D Step 7

💡 Hint

Look for 'Alert sent to team' in the 'Log Entry' column in the execution_table.

If the API always returns 200 OK, how would the Alert Triggered column change?

A It would always be No

B It would alternate Yes and No

C It would always be Yes

D It would be Yes only on wait steps

💡 Hint

Refer to the variable_tracker for Alert Triggered values when Response Status is 200 OK.

Concept Snapshot

API Monitoring and Alerting:
- Define API endpoint and check frequency
- Send requests regularly
- Check response status code
- Log success if 200 OK
- Trigger alert if error status
- Notify team on alert
- Repeat monitoring cycle

Full Transcript

API monitoring and alerting involves regularly sending requests to an API endpoint and checking the response status. If the response is successful (status 200), the system logs success. If an error occurs (like status 500), it triggers an alert and notifies the team. The process repeats at set intervals until monitoring stops.

Practice

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