> For the complete documentation index, see [llms.txt](https://infobipengineering.gitbook.io/handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infobipengineering.gitbook.io/handbook/engineering-culture/paid-interventions.md).

# Paid Interventions

Working overtime **should not be a standard**. We don't want you burned out, frustrated, tired, and sad. In general, we would like to foster a healthy work-life balance environment and encourage everyone to work the usual work hours. Overtime work has to be agreed upon and approved by your line manager in advance. Overtime is compensated by being paid or by taking time off as compensation for the hours you worked.

We have two types of overtime:

* Readiness
* Intervention.

Some teams in the company and some developers holding critical services sign a contract addendum where they are responsible for being on call a certain number of days in a month, meaning they need to be available to answer a call within 10 minutes and start working on an issue in a maximum of half an hour. This is compensated in itself even if no calls arrive. Concerning interventions, in the majority of teams, they happen rarely. 

#### Readiness and Intervention in Practice <a href="#ur-worklifebalance-overtimeandworkfromanywhere-readinessandinterventioninpractice" id="ur-worklifebalance-overtimeandworkfromanywhere-readinessandinterventioninpractice"></a>

Check these three examples to see how readiness and interventions function in practice:&#x20;

* Readiness: I'm an Engineer in our API team which is the owner of critical API endpoints. I signed a contract addendum for readiness. In my team, we are all in a readiness rotation, and every day we change who is on duty after working hours. We are all compensated for being in a readiness state. This day I'm on duty. One endpoint of our public API is returning the error and I'm called by OpsGenie, the automated alerting and incident response tool, to check what is the issue. I checked in on the #incident\_management Slack channel within 10 minutes and started working on the issue. The issue was in the last deployment, I fixed it and let the support know which clients and how much traffic were affected.
* Unplanned intervention: I'm an Engineer in our internal team who works on SuperUser product, an internal tool that is used by Support and Account Managers. Incidents happen rarely on the services which my team is owner, from 1 to 10 times per year. I'm called outside of working hours by our Support team who have exhausted all typical troubleshooting steps they usually go through.  Our product isn't accessible. In Engineering we are responsible to fix what we build and at that time I was at home and I checked in on Slack and started to see what is the root cause. I solved the issue and deployed a new version of the application in production. After that, I filled out our internal form with a ticket that I worked on and the start and end date so I can get compensated for the hours I was online.
* Planned intervention: I'm an Engineer in the team who works on our Contact Center solution and we have scheduled database migration during the weekend in order to lower the impact on customers. I agreed with my team members that I will be responsible for checking if everything is ok with database migration for Contact Center. I was online during one period of the weekend when migration happened and everything went ok with it. After the migration, I filled our internal form with the details of intervention and the start and end date so I can get compensated for the hours I was online.

The "You build it, you own it" medal has another side that says "You break it, you fix it", meaning that we should work on stability and technical debts and include technical plans on the roadmap to prevent incidents. If the incident happens, the person or the team owning it are accountable to fix the situation, even if it's outside their usual working hours.&#x20;


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://infobipengineering.gitbook.io/handbook/engineering-culture/paid-interventions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.