---
# System prepended metadata

title: OKR - Uptime

---

# OKR - Uptime

- Objectives. Increase quality of our work in oder to have more reliable product & faster development processes

- Key result. Increase Uptime

- Initiatives.  They are plans, initiatives are the smaller tasks you have to accomplish to achieve each key result.
    - What are we going to DO to drive progress to key results?
        - Monitoring app performance
        - Alerting system for downtime
        - Incidents documentation
        - Decrease production exception
        - Ensure APIs response time within 400 ms
        - Hold retrospective to determine root cause every time we have an outage.
        - decrease time to resolution when errors do occur on production
        - 
    
    - What should we start doing first?
        - measure the uptime
            - Observation: how many 500 or connection error in logs?
            - Measure: "tail" the response logs of the web servers/services and dump them into a logs-processing system.
            - Analyze: take a daily availability measurement as the percentage of 200 OK responses vs. the total number of requests.
            - But thats not enough. you would need a blackbox "prober" (Testing externally visible behavior as a user would see it.) to check it for all type of devices and prob the site from the perspective of user and not just a 200 

        - What are the reasons of downtime? 
            - Infrastructure is down?
            - legacy applications not reachable
            - Code error 
            - Deployment failures




Resources:
https://cloud.google.com/blog/products/gcp/available-or-not-that-is-the-question-cre-life-lessons


--------------

What is uptime?
- product availability
- FE/PO knows if its down
- Uptime from user perspektive
- FE is working but BE not working or the connection is lost
- System components should be up and running to say the whole applicaton is working
- Define whoch components should be assumed as main components of an application to consider as working application
    - based on user enaggement with the component
    - Backend avialability
    - 
- monitoring and alerting 
- SLA? NO
- Stability
- How to define where is the issue in an application?is it on our side or somewhere else? cloude provider-Legacy applications,...


Final questions:
- What does it mean for us as DI Uptime? 
    - Depends on how important is that component
- How to define different parts/components of an application
- Ask all POs if they know how much is our Uptime
- Define how to calculate the uptime of each product
