SLA and uptime tracking in Rest API - Step-by-Step Execution

Concept Flow - SLA and uptime tracking

Start Monitoring

↓

Check Service Status

↓

Is Service Up?

No→Record Downtime

|Yes↓

Record Uptime

↓

Calculate Uptime %

↓

Compare with SLA

↓

Report Status

↓

Repeat

This flow shows how a system checks if a service is up, records uptime or downtime, calculates uptime percentage, compares it to the SLA, and reports the status repeatedly.

Execution Sample

Rest API

def check_service():
    status = get_service_status()
    if status == 'up':
        record_uptime()
    else:
        record_downtime()
    uptime = calculate_uptime()
    return uptime

This code checks if a service is up or down, records the result, calculates uptime percentage, and returns it.

Execution Table

Step	Action	Service Status	Record	Uptime %	SLA Met?
1	Check service status	up	Record uptime	N/A	N/A
2	Calculate uptime	up	N/A	99.5%	N/A
3	Compare with SLA (99.0%)	up	N/A	99.5%	Yes
4	Report status	up	N/A	99.5%	Yes
5	Check service status	down	Record downtime	N/A	N/A
6	Calculate uptime	down	N/A	98.7%	N/A
7	Compare with SLA (99.0%)	down	N/A	98.7%	No
8	Report status	down	N/A	98.7%	No
9	End monitoring cycle	N/A	N/A	N/A	N/A

💡 Monitoring cycle ends after reporting status for current check.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 5	After Step 6	Final
status	N/A	up	up	down	down	down
record	N/A	uptime	uptime	downtime	downtime	downtime
uptime_percentage	0%	N/A	99.5%	N/A	98.7%	98.7%
sla_met	N/A	N/A	Yes	N/A	No	No

Key Moments - 3 Insights

Why do we record uptime only when the service status is 'up'?

Because uptime means the service is working properly. The execution_table rows 1 and 5 show recording uptime only when status is 'up' and downtime otherwise.

How is the uptime percentage calculated after each check?

The uptime percentage is updated based on recorded uptime and downtime over time, as shown in execution_table rows 2 and 6 where uptime % changes after each status check.

What does it mean if SLA is not met?

It means the uptime percentage is below the agreed SLA threshold. Execution_table rows 7 and 8 show SLA not met when uptime % is 98.7% which is below 99.0% SLA.

Visual Quiz - 3 Questions

Look at the execution_table, what is the service status at step 5?

A up

B down

C unknown

D N/A

💡 Hint

Check the 'Service Status' column in execution_table row for step 5.

At which step does the uptime percentage first get calculated?

A Step 2

B Step 1

C Step 4

D Step 5

💡 Hint

Look at the 'Uptime %' column in execution_table to find when it first shows a value.

If the service status was always 'up', what would the 'sla_met' variable be after step 6?

A No

B N/A

C Yes

D Depends on uptime %

💡 Hint

Refer to variable_tracker row for 'sla_met' and consider that uptime % would stay above SLA.

Concept Snapshot

SLA and uptime tracking:
- Check service status regularly
- Record uptime if service is up, downtime if not
- Calculate uptime percentage over time
- Compare uptime % with SLA threshold
- Report if SLA is met or not
- Repeat monitoring continuously

Full Transcript

This visual execution trace shows how a system monitors a service's availability to track SLA and uptime. It starts by checking if the service is up or down. If up, it records uptime; if down, it records downtime. Then it calculates the uptime percentage based on recorded data. This percentage is compared to the SLA target to decide if the SLA is met. The system reports the status and repeats this cycle continuously. Variables like service status, record type, uptime percentage, and SLA met flag change step-by-step as shown in the tables. Key moments clarify why uptime is recorded only when service is up, how uptime percentage updates, and what it means when SLA is not met. The quiz questions help reinforce understanding by referencing specific steps and variable values.