# Home Page Guide Here are the main **operational performance indicators** of the **Elven Platform**, clearly presented to provide a comprehensive overview of what is working well and what can be improved. This **dashboard** was designed to make it easier to understand the **impact** of each **metric** and to support faster and more accurate **decision-making**. When analyzed together, these **metrics** offer a clear and complete view of **system performance**, enabling you to make quick and precise decisions to ensure everything is running as efficiently as possible. Now, let’s explore each **indicator** with practical examples, explaining how you can apply them in your daily routine in a simple and intuitive way. It’s worth noting that all these **indicators** are available in the **Insights section**, where you’ll also find detailed **documentation** that dives deeper into each **metric**, helping you understand their **impact** on **system operations**. {% embed url="" %} ## **Uptime** **Uptime** shows the **percentage of time** the system was **available** and running **without interruptions**. The closer to **100%**, the better the **user experience**. **Example**:\ Imagine an **e-commerce** platform during **Black Friday**. An **uptime** of **99.9%** means the site was functional almost the entire time, ensuring **sales** and **customer satisfaction**. However, even **0.1% of downtime** can result in **thousands of reais** in lost revenue. ## **Downtime** This indicator, **Downtime**, shows the **total time** the system was **unavailable** during a specific period. It helps identify when **critical issues** occurred. **Example**:\ Suppose a **customer support application** was down for **1 hour**. This could lead to **longer queues**, **customer frustration**, and a direct impact on the company’s **reputation**. ## **Outages** Here, in **Outages**, we measure how many times the system experienced **interruptions**, even if they were brief. Knowing the **frequency of failures** is essential to understand whether there is a **recurring pattern** that needs to be addressed. **Example**:\ A **streaming service** that experiences **10 interruptions** in a single day may be worse for the customer than one **longer outage**. ## **Latency (Max, Min, and Average per Hour)** These indicators assess the **system’s response speed**, measuring the **maximum**, **minimum**, and **average latency** in **milliseconds**. **Low latency** means everything is running smoothly. **Example**:\ In a **delivery app**, **high latency** can lead to delays for the customer when trying to **view the menu** or **complete an order**. If the **average latency** is around **300ms**, it might be time to **optimize performance**. ## **Total Incidents** This **metric** shows how many **incidents** were recorded during the analyzed period. Understanding the **volume** helps the **team** prioritize **solutions** and optimize **processes**. **Example**:\ If the **dashboard** shows that there were **20 incidents** in the past week, it’s time to identify whether they were caused by the **same issue** or if it’s necessary to review the **infrastructure**. ## **Total Response Effort** This **data** reflects the total **effort** made by the **team** to respond to **incidents**, although it’s not always a **measurable number**. **Example**:\ If resolving an **incident** requires **overtime** from the team, it may indicate that the available **tools** are not sufficient, and it might be necessary to invest in **automation**. ## **MTTA (Mean Time to Acknowledge)** Here we evaluate the **average time** the **team** takes to **acknowledge** an **incident** after it has been reported. The lower the **MTTA (Mean Time to Acknowledge)**, the faster the **resolution process** begins. **Example**:\ Imagine the system detects a **server overload issue**. If the **MTTA** is just **2 minutes**, the team can act quickly to prevent a **major failure**. ## **MTTR (Mean Time to Resolve)** **MTTR (Mean Time to Resolve)** shows the **average time** needed to **resolve issues**. It is an essential **metric** for evaluating **operational efficiency**. **Example**:\ If a **network issue** takes **4 hours** to resolve, but a similar **incident** was fixed in just **1 hour** after **configuration improvements**, this can serve as a basis for future **optimizations**. ## **Last Incidents** Here, we present a detailed view of the **most recent incidents**. This section provides essential **information** about each event, such as the **Incident ID**, **Status**, **description**, and **timestamp**, making it easier to **track** and **analyze** the actions taken by the **team**. **Example**:\ Imagine an issue was detected on the **production server**, causing **system slowness**. The **incident** was recorded at **2:30 PM** and resolved by **2:45 PM**. The **description** might be something like “**Performance issue due to traffic spikes**.” The **status** would indicate it was "**Resolved**."\ This kind of **tracking** allows the team to understand the **impact** of each incident and how long it took to **resolve**, helping with future **decision-making** to prevent similar failures. ## **Last Alerts** Here, we provide a detailed view of the **most recent alerts** recorded in the system, offering a clear analysis of conditions that require **immediate attention**. This allows the **team** to take **corrective actions** quickly, before they escalate into bigger problems.\ In this section, you’ll find essential **information** about each **alert**, such as the **Alert ID**, **Status**, **description**, and the **time** the alert occurred, making it easier to **track** and **analyze** the actions taken by the team. **Example**:\ Suppose the system detects an alert for "**Disk usage above 90%**" on a server. The **alert** is triggered at **10:30 AM** and resolved by **10:40 AM**, with the team performing a **cleanup of unnecessary files**. The **status** of the alert would be "**Resolved**."\ This **alert history** helps the team identify which areas need more **monitoring** or **improvements**, such as optimizing **disk management**, helping to prevent the alert from recurring. ## **Responder Incident Volume** Here, in **Responder Incident Volume**, we have a **bar chart** that illustrates the number of **incidents assigned** by **Responder type**, such as **“SRE”**, **“No Responder”**, among others. This chart provides a clear view of how the **workload** is distributed among **team members**, helping to identify potential **overloads** or **imbalances** in **task distribution**. **Example**:\ Imagine that, when viewing the **chart**, you notice that the **SRE team** is being assigned to **70% of the incidents**, while other groups like **“No Responder”** have a much lower percentage. This could indicate that the **SREs are overloaded** or that there’s an opportunity to **redistribute the workload**.\ By better **balancing** the load among **responders**, you can improve the team’s overall **efficiency** and reduce the **pressure** on members handling an **excessive volume** of incidents. reduzir a pressão sobre os membros que estão lidando com um volume excessivo de incidentes. ## **Highest MTTA by Responder** In **Highest MTTA by Responder**, you can view which **Responders** have the **highest average time** to **acknowledge an incident**. This data is crucial for identifying potential **bottlenecks** in the **response process** and helps highlight areas where the team can improve its **agility** in handling incidents. **Example**:\ Imagine that, when analyzing the **chart**, you notice that the **SRE team** has an **average MTTA** of **20 minutes**, while other teams show significantly lower values, such as **5 minutes**. This may indicate that **SREs** are taking longer to **acknowledge** and begin resolving issues, possibly due to **lack of resources** or **task prioritization**.\ With this information, it’s possible to investigate the cause of the delay and implement changes to reduce this time, such as improving **monitoring processes** or providing additional **training** to the team so they can **respond more quickly**. ## **Highest MTTR by Responder** In **Highest MTTR by Responder**, the goal is to analyze the **average time** each **Responder** takes to **resolve incidents**. Similar to **MTTA**, but focused on **problem resolution**, this **metric** is essential for identifying which **team members** may be facing challenges in resolving incidents efficiently. **Example**:\ Suppose that when reviewing the **chart**, you find that the **SRE team** has an **average MTTR** of **2 hours**, while other **responders** are resolving incidents in less than **30 minutes**. This data may suggest that the **SRE team** is facing greater difficulties in **problem resolution**, whether due to **task complexity** or **lack of resources**.\ Analyzing **MTTR** allows you to take specific actions, such as providing additional **training** to the team, improving **tool support**, or **redistributing incidents** more evenly — all with the goal of optimizing **response time** and increasing **efficiency**. ## **Glossary of Technical Terms** **Uptime: Percentage of time** the system is **available** and **operational**, without interruptions. Indicates **system reliability** and **stability**. **Downtime: Period of time** when the system is **inactive** or **unavailable**, directly affecting the **user experience** and **operations**. **Outages: Interruptions** or **failures** in the system, even if brief. Measuring the **frequency** helps identify **patterns** and potential **causes**. **Latency: Response time** of a system or application, measured in **milliseconds**. Indicators include **maximum**, **minimum**, and **average latency**. **Incident:** An **unexpected event** that causes **service interruption** or **degradation**. It can vary in **severity** and **operational impact**. **Total Response Effort:** Total **effort** spent by the **team** to handle **incidents**, including **time**, **resources**, and **actions** taken. **MTTA (Mean Time to Acknowledge): Average time** the team takes to **acknowledge** an **incident** after being notified. Reflects **efficiency** in the **initial detection** of issues. **MTTR (Mean Time to Resolve): Average time** required to **resolve** an **incident**. Indicates **operational efficiency** and the ability to **respond to problems**. **Alerts: Automatic notifications** generated by **monitoring systems** when conditions requiring **immediate attention** are detected. **Responder:** The **person** or **team** assigned to handle specific **incidents** or **alerts**, such as **SRE teams**. **SRE (Site Reliability Engineering):** A practice that applies **software engineering principles** to manage systems and improve **reliability** and **performance**. **Responder:** Pessoa ou equipe designada para lidar com incidentes ou alertas específicos, como equipes de SRE. **SRE (Site Reliability Engineering):** Prática que aplica princípios de engenharia de software para gerenciar sistemas e melhorar a confiabilidade e a performance.