= This is the process =
This document is an authoritative description of the process. This document supersedes all prior documents on the process.

= Deviating from the process =
You may deviate from the process at any moment. A deviation should be communicated to the dev-team, preferably in the Zulip topic about the applicable incident, as soon as possible after deciding to deviate.

= Checklist =
This checklist is a shorter, imperative version of [[Incident Handling#Full_procedure|the longer procedure below]]. You're encouraged to read the [[Incident Handling#Full_procedure|full procedure]] at least once to improve your understanding of the core material.

=== Critical Incidents ===
Critical incidents must be resolved within 16 hours.

# Acknowledge trigger in Zabbix.
# Check if the incident is still ongoing.
# Determine whether the incident is ongoing
# Determine whether clients are potentially affected, if so:
## notify the affected clients (Slack preferred)
## share the message sent to the client in the incident Zulip thread
# Document all actions taken in the Zulip topic.
# Create a plan of action.
# Execute plan and document results in Zabbix thread.
# If unresolved, create a new plan.
# When resolved:
## Verify trigger is no longer firing.
## Decide on when to notify affected clients (that you have notified of the incident), the incident has been resolved, and communicate this internally
## Mark Zulip topic as resolved if no other incidents for the host.
## Check for related triggers and resolve them.

=== Non-Critical Incidents ===
Non-critical incidents must be acknowledged within 9 hours and resolved within 1 week.

# Acknowledge in Zabbix thread
# Check metrics sheet for existing milestone
## If a milestone exists:
### Add Lynx project ID to Zulip topic
### Add 🔁 emoji if ID already reported
## If no milestone exists:
### Add to metrics sheet
### Create Lynx project (priority 99, then 20 after estimation)
### Create Kimai activity
### Document IDs in Zulip topic

=== Informational Incidents ===
Informational incidents must be acknowledged within 72 hours.

# Acknowledge in Zabbix
# Verify issue
# Take action if needed

=== External Reports ===

# Acknowledge receipt
# Classify report as critical, non-critical or informational.
# Create a Zulip topic in SRE # Critical, SRE ## Non-critical or SRE ### Informational (depending on classification) and add sufficient details.
# Proceed with checklist above for the type of incident.

= Full procedure =

== General Rules ==

# When an incident is in progress, and person A is handling it, then all incidents in area X, are handled by person A, rather than the FR. Unless working day ends. Person A should communicate clearly to FR when their day is over.
# FR always has the last word on what solution to apply for resolving an incident.

== Critical incidents ==
'''Critical incidents are resolved within 16 hours.'''

As first responder you take on the responsiblity of seeing an incident resolved. This does not mean that you are the person required to do all the work. You can attempt to involve others to help you (often referred to as escalating the incident), but since other are not on-call, they are not obliged to help you, especially outside of normal working hours.
Involving multiple people can quickly be required if multiple critical incidents with different causes occur simultaneously. In that case, the First Responder usually takes on a more information management role and steers those that are brought on into resolving the issues. (Example: if a server crashes, several critical triggers can fire, but the underlying cause can quite quickly be determined to be a single issue, the crashed server. So you wouldn't need to call in people to manage each incident. But a client's service being down in one cluster while in a different cluster a different VM no longer boots is likely to be to different issues, so in order to resolve them on time you'd want to call in help to resolve the incident in time).

=== Process ===
The general process is made up of the following steps. Each step has additional information on how to handle/execute them in the sections below.
# Take responsibility for seeing the incident resolved
# Determine if incident is still ongoing
# If ongoing: Communicate to affected clients that the issue is being investigated
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# Resolve incident + cleanup

During working on an incident it is expected that all communication is done in the incident's thread. This means all information to a problem can be found in a clear a predictable place. Sometimes an incident can be resolved by work done in another incident. In that case, it is required to post a link to that thread in the incident's thread with the comment that the resolution is done in that thread.

==== Acknowledge the incident on Zabbix ====
The first step is to take responsibility for seeing the incident resolved by acknowledging the incident on Zabbix. Simply acknowledging the trigger suffices. It is however entirely possible that multiple critical incidents are firing at the same time. This can be a coincidence, or can be because of a share cause of failure. For example, a server crashing will cause server VMs to reboot, or the router having an connectivity issue will lead to most other VMs having connectivity issues as well. If there are multiple critical incidents, it is advised to quickly observe what's ongoing, Zabbix is the best source of firing triggers for this, and pick the incident that is likely the root cause to

* Acknowledging an incident on Zabbix will stop Zabbix from calling the First Responder to notify them of the ongoing incident. And stops Zabbix from posting reminders on Zulip.

==== Determine if incident is still ongoing ====
The next step is to check if the reported problem is still ongoing. Depending on the observations made here your process to follow and steps needed to resolve the incident can change. There are three options:
# The trigger resolved itself and the problem cannot be observed. Example: HTTPS is down for a site, but the FR can access the site through HTTPS without incident.
# The trigger resolved itself and the problem can still be observed.
# The trigger is still firing but the problem cannot be observed: Our triggers might not be perfect, so it could be that something else is causing it to fire. A simple example would be that Zabbix reports that the the DNS for a site can't be resolved, but in reality there's a bug in the script we wrote that checks if the DNS resolves and the DNS resolves fine. Final note: keep in mind that an 'it works on my machine' does not necessarily mean it works for most other people, so depening on the trigger you need to do some evaluations if your tests suffice.

In order to make sure you are actually trying to observe the same thing as the trigger is looking for, make sure to check the trigger definition and the current data of the associated item(s). Some triggers might fire if one of multiple conditions is met (Such as a trigger that monitors the ping response time firing if the value exceeds a certain threshold, or if no data for a certain period of time was observed).

Make sure to report your findings in the incident's thread. It's advised to post a screenshot of the relevant item(s) and your own observations. (Continuing the ping example, you would post a screenshot of the relevant values, state your conclusion why the trigger is firing, and your own observations/pings)

==== Communicate to affected clients ====
If the incident is still ongoing and the service is down, we need to communicate to affected clients that we are aware of the problem and that we are investigating it. This is because critical incident usually mean the service is down, something the clients can notice/are affected by, so we to be transparent that something is going on. There are some additional notes to this though:
* If an incident has already resolved itself and the problem is no longer observable, we don't communicate anything. Doing so might only cause confusion, and since the client has not reported any issues, they have not had a noticeable problem with it themselves.
* Although a critical incident generally means that the client service is down or experiencing reduced service, not all critical incidents are of that nature. Some are more administrative, or are only an issue for Delft Solutions itself. As of writing I don't have an exhaustive list, but here is those I can think of:
** SSH Service is down: We don't have any clients that SSH into their services, so it's generally not a problem. But SSH is mostly used for SRE maintenance and publishing new builds. The SRE maintenance is an internal problem, so no need to communicate to the client. The publishing is done to Kaboom, preventing new builds from being published, and the two SM VMs.
** No backup for x days: Clients don't notice it if a backup is running late, so no need to communicate with clients. Just need to make sure the backup gets completed
** SSL certificate is expiring in < 24 hours: This is a bit dependent on how soon this incident is being handled, but if it handled quickly, the certificate never actually expired, and there has not been any disruption to the client's service, so no need for communicating about it.
* Determining which clients are being affected can be done by looking at the host's DNS in the trigger, and/or looking up the VM in Proxmox and checking the tags of the VMs for client names. In the case that this issue is causing multiple other critical triggers to fire, you would have to check for which clients are affected by those incidents.
* Communicating to DS about ongoing incidents is usually assumed to be automatically have been done by the fact that the incident was reported on Zulip.

As always, report the decisions taken and actions made in the incident thread. (e.g.: I've sent a message in the Slack to let Kaboom know that we aware of problem x, and that we are investigating it)

==== Communicate plan/next steps + Communicate findings/results of executed plan ====
This is the main part of handling an incident. There are several actions you can take in these steps, but at the basis they consist of sharing your next steps, performing those, and reporting the results. The reason all this needs to be reported is to ensure that all known information about a problem is logged, making it easier for someone else to be onboarded into the issue, for later reference if a similar issue is encountered, and even for use during the incident itself in case an older configuration needs to be referenced after you changed it.
The objective from these steps is determining what is actually wrong and how to resolve it. Depending on the observations made earlier on whether the incident is still ongoing and is (still) observable your investigation can go into different directions. (e.g. Find the underlying cause for a trigger, or determining why the trigger is firing while it likely shouldn't, and then how to resolve that underlying cause or how to update the trigger to work better)

There are three main types of steps defined, but you are not limited to these:
# Hypothesis: If you have an idea what could be causing it, you would state your hypothesis and your next step would be to prove that hypothesis. For example, for an incident 'SSH service is down on X' your hypothesis could be that this is due to 'MaxStartups' throttling, which can be proven by 'grep'ing journalctl for that, and compare the start and end times of throttling with the timestamps of the item reporting the status of the SSH service.
# Information gathering: Sometimes it just helps to get some facts about the situation collected. What is usefull information that is relevant depends on the triggers, but some examples are: The syslog/journalctl of the host from around the time of the incident (it can contain a reference to the an underlying problem in various levels of explicitness), the ping response from several hosts on the route to a host or a traceroute (this helps with networking issues). The gathered information is usually intended to help you come up with an hypothesis on what's wrong.
# Investigative: The most rigorous of process. The full process is described here originally [https://docs.google.com/document/d/1AQYJM1Q9l2Tyk6zfCVaQ2aEq-dpbfUH5okE88bpKkhw/edit#heading=h.5fq2skijqbdc Drive - Final Coundown - General Investigative Process]. To summarize, when you don't know why something is failing, and/or don't have any decent hypotheses to follow up, you can follow this process to systematically find the problem.

Regarding the resolution to an incident: The resolution to any incident is usually one of two things:
# Fix the underlying problem.
# Fix the trigger itself.
Fixing the trigger is relatively straightforward, but do make sure document in the thread what you changed to which trigger.
Fixing the underlying problem can be more complex. A trade-off needs to be made sometimes between resolving technical debt, or simply patching the current system to resolve the issue. We usually look for a resolution that ensures that the problem won't re-occur soon, or makes it unexpected/unlikely for the problem to re-occur. Taking into account the time frame that is available to resolve the incident you can make some trade-offs. An example would be: normal backups of VMs are failing due to the Proxmox backup server being down/unreachable and it is determined that this cannot be resolved at that moment. We can set up automatic backups to local storage temporary to resolve the immediate problem and ensure we keep our SLO's versus setting up a new Proxmox Backup server at a different location. Since we don't have much time to resolve the problem, the resolution would be to set up the automatic backups to local storage, and set up a new Proxmox Backup Server later as a seperate issue.

===== Some known issues and their resolutions =====
* SSH service is down: The internet is a vile place. There's constant port scanning and hacking attempts ongoing to any machine connected to the internet (mostly IPv4). Due to this, SSH has a throttling functionality build in to prevent a system from being DDOS'ed by the amount of malicious SSH requests. This throttling can cause the Zabbix server from being denied an SSH connection, of which several failures fire this trigger. This hypothesis can be proven with a `journalctl -u ssh | grep 'MaxStartups throttling'` (you probably want to select a relevant time period with `--since "2 hours ago"` or something similar to prevent having to process a month of logging). You can then compare the throttling start and end times with the timestamps of the item data itself. The resolution for the issue is to add our custom ssh configuration [https://chat.dsinternal.net/#narrow/stream/23-SRE---General/topic/DS.20Whitelisted.20Custom.20SSH.20configuration/near/1620 Custom SSH Configuration].
* No backup for 3 days: Are S3 backup is very slow. Not much to prove as an underlying issue here. What needs to be done is check that the backup process is ongoing. The Zabbix latest data can be checked to verify that backups are running by checking that that days backups were done for the smaller buckets. The devteam email can be checked for if the backup process could not start on day due to it already running (it takes 24+ hours, and an attempt to start it is done each day by cron).
* git.* HTTPS is down: On Sunday mostly, Gitlab gets automatically updated, but this incurs some downtime as the service is restarted. This is usually short enough to not be reported to Zulip as per our settings, but sometimes it's longer. If the service does not stay down, the issue can be just resolved.

==== Resolve incident + cleanup ====
When you've executed and verified the resolution in the previous steps we can proceed resolving the issue in our Mattermost integration. Resolving an incident can be done by doing the following:
# Verify that the trigger is no longer firing. An incident will be immediately re-opened if the trigger is still firing, and the incident cannot be considered resolved if the trigger is still firing. If the trigger is still firing but you're sure that you've resolved the problem, you might need to force the item the trigger depends on to update. This can be done by finding the item in the host's configuration on Zabbix and selecting 'Execute Now', after a short period this should force Zabbix to re-execute the item. You can check the timestamps in the latest data of an item to check if it was updated.
# Close the incident by marking the topic as resolved, when there are no other triggers firing for the host.

Unfortunately, some problems cause multiple critical and non-critical triggers to fire. This means we have to check Zabbix and Zulip for other fired triggers and ongoing incidents. The goal is to identify critical and non-critical incidents that were caused by the incident/underlying issue you just resolved.
# First, these incidents need to be acknowledged on Zabbix, and in the acknowledgement message you mention the incident/problem that caused this.
# Next, check the incident tracked by the integration on Mattermost using the `?ongoing` command. Resolve incidents that were (re-)opened by this incident by executing the following steps. If the first two fail (problem still persists, trigger is still firing), the incident needs to considered it's own issue and the relevant process needs to be followed (critical or non-critical depending on criticality).
## Ensuring the mentioned problem is no longer observable
## The trigger has resolved (You might need to force an update with `Execute Now`).
## Posting a link to the main incident you resolved with the comment that the underlying problem was resolved in that topic.
## Closing the incident by marking the topic as resolved, when there are no other triggers firing for the host.

When you are done, there should be no more critical triggers firing in Zabbix or open in the Zabbix-Mattermost integration, for which no-one has taken responsibility or you have taken responsibility for and are not actively handling.

== Non-Critical incidents ==
* Non-critical incidents are acknowledged within 9 hours and resolved within one week.

=== Acknowledging ===
Fully acknowledging a non-critical incident requires the following tasks to have been completed:
* Acknowledging the incident on Zabbix, which means you take responsibility of completing the steps listed below.

The next steps don't have to be done immediately, as they have dependencies, but be started and scheduled for completion the next work day.

Check if there's already a uncompleted milestone for this host with this issue in the metrics sheet.
If a milestone is already present:
* Report in the topic the Lynx project ID for resolving this issue.
* If the ID has already been reported in the topic, we don't want to report it again and again, instead add the 🔁 emoji (:repeat:) under the zabbix bot alert

If a milestone is NOT already present:
* Add the non-critical incident as a milestone in the metrics sheet, following the naming convention
** Start date is the date of the incident
** DoD states what needs to be true for the non-critical incident to be consider resolved
* Add the non-critical incident to Lynx as a project
** Follow the naming convention below for the title & project ID
** Tasks need to be added
** Final tasks needs to have the SLO deadline set as 'constraint'
** Project priority is set to 99 while not estimated yet. After the estimation is done, the priority should be set to 20
** The tasks are estimated for SP
* The Lynx project ID is reported in the non-critical incident's topic on Zulip, and logged in the metrics sheet
* A Kimai activity is created in Kimai for the non-critical incident, following the naming convetion

==== Naming convention ====
* Kimai activity name needs to follow the pattern: '<YYYY-MM> <problem_title>'. For <problem_title>, incorporate the trigger title and hostname for clarity.
* Milestone name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project ID needs to follow the pattern: 'SRE<YYMM><XXX>', where <XXX> is some three letter shorthand that relates to the problem/host

== Informational incidents ==
* Informational incidents are acknowledged within 72 hours

Checklist
# Acknowledge on Zabbix
# Sanity check the event, post result in thread
# If action needed, perform action

== If an incident is reported by other means than the Zabbix-Zulip integration ==
Besides the automated Zabbix-Zulip integration, incidents can also be reported through emails from cron jobs, direct emails from customers, or topics in SRE General (such as alerts about Zulip updates or issues raised by colleagues), etc.
# Acknowledge receipt.
# Classify the incident as critical, non-critical, or informational.
# Create an topic in the relevant SRE channel, stating the problem and that you is responsible for resolving it.
# Proceed to treat the incident according to the criticality you just classified it as. (So for a critical incident, it means you now start the critical incident handling process)

== Handover ==
See [[Handover]]

Incident Handling

2025-10-21T11:10:24Z

Jakobbuis: /* Deviating from the process */

= This is the process =
This document is an authoritative description of the process. This document supersedes all prior documents on the process.

= Deviating from the process =
You may deviate from the process at any moment. A deviation should be communicated to the dev-team, preferably in the Zulip topic about the applicable incident, as soon as possible after deciding to deviate.

= Checklist =
This checklist is a shorter, imperative version of [[Incident Handling#Full_procedure|the longer procedure below]]. You're encouraged to read the [[Incident Handling#Full_procedure|full procedure]] at least once to improve your understanding of the core material.

=== Critical Incidents ===
Critical incidents must be resolved within 16 hours.

# Acknowledge trigger in Zabbix.
# Check if the incident is still ongoing.
# Determine whether the incident is ongoing
# Determine whether clients are potentially affected, if so:
## notify the affected clients (Slack preferred)
## share the message sent to the client in the incident Zulip thread
# Document all actions taken in the Zulip topic.
# Create a plan of action.
# Execute plan and document results in Zabbix thread.
# If unresolved, create a new plan.
# When resolved:
## Verify trigger is no longer firing.
## Decide on when to notify affected clients (that you have notified of the incident), the incident has been resolved, and communicate this internally
## Mark Zulip topic as resolved if no other incidents for the host.
## Check for related triggers and resolve them.

Common issues that have occurred previously, and ''could'' occur again:
* SSH down: Check MaxStartups throttling, apply custom SSH config
* No backup: Verify backup process is running, check the devteam email
* HTTPS down on Sunday: this can be due to GitLab updates

=== Non-Critical Incidents ===
Non-critical incidents must be acknowledged within 9 hours and resolved within 1 week.

# Acknowledge in Zabbix thread
# Check metrics sheet for existing milestone
## If a milestone exists:
### Add Lynx project ID to Zulip topic
### Add 🔁 emoji if ID already reported
## If no milestone exists:
### Add to metrics sheet
### Create Lynx project (priority 99, then 20 after estimation)
### Create Kimai activity
### Document IDs in Zulip topic

=== Informational Incidents ===
Informational incidents must be acknowledged within 72 hours.

# Acknowledge in Zabbix
# Verify issue
# Take action if needed

=== External Reports ===

# Acknowledge receipt
# Classify report as critical, non-critical or informational.
# Create a Zulip topic in SRE # Critical, SRE ## Non-critical or SRE ### Informational (depending on classification) and add sufficient details.
# Proceed with checklist above for the type of incident.

= Full procedure =

== General Rules ==

# When an incident is in progress, and person A is handling it, then all incidents in area X, are handled by person A, rather than the FR. Unless working day ends. Person A should communicate clearly to FR when their day is over.
# FR always has the last word on what solution to apply for resolving an incident.

== Critical incidents ==
'''Critical incidents are resolved within 16 hours.'''

As first responder you take on the responsiblity of seeing an incident resolved. This does not mean that you are the person required to do all the work. You can attempt to involve others to help you (often referred to as escalating the incident), but since other are not on-call, they are not obliged to help you, especially outside of normal working hours.
Involving multiple people can quickly be required if multiple critical incidents with different causes occur simultaneously. In that case, the First Responder usually takes on a more information management role and steers those that are brought on into resolving the issues. (Example: if a server crashes, several critical triggers can fire, but the underlying cause can quite quickly be determined to be a single issue, the crashed server. So you wouldn't need to call in people to manage each incident. But a client's service being down in one cluster while in a different cluster a different VM no longer boots is likely to be to different issues, so in order to resolve them on time you'd want to call in help to resolve the incident in time).

=== Process ===
The general process is made up of the following steps. Each step has additional information on how to handle/execute them in the sections below.
# Take responsibility for seeing the incident resolved
# Determine if incident is still ongoing
# If ongoing: Communicate to affected clients that the issue is being investigated
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# Resolve incident + cleanup

During working on an incident it is expected that all communication is done in the incident's thread. This means all information to a problem can be found in a clear a predictable place. Sometimes an incident can be resolved by work done in another incident. In that case, it is required to post a link to that thread in the incident's thread with the comment that the resolution is done in that thread.

==== Acknowledge the incident on Zabbix ====
The first step is to take responsibility for seeing the incident resolved by acknowledging the incident on Zabbix. Simply acknowledging the trigger suffices. It is however entirely possible that multiple critical incidents are firing at the same time. This can be a coincidence, or can be because of a share cause of failure. For example, a server crashing will cause server VMs to reboot, or the router having an connectivity issue will lead to most other VMs having connectivity issues as well. If there are multiple critical incidents, it is advised to quickly observe what's ongoing, Zabbix is the best source of firing triggers for this, and pick the incident that is likely the root cause to

* Acknowledging an incident on Zabbix will stop Zabbix from calling the First Responder to notify them of the ongoing incident. And stops Zabbix from posting reminders on Zulip.

==== Determine if incident is still ongoing ====
The next step is to check if the reported problem is still ongoing. Depending on the observations made here your process to follow and steps needed to resolve the incident can change. There are three options:
# The trigger resolved itself and the problem cannot be observed. Example: HTTPS is down for a site, but the FR can access the site through HTTPS without incident.
# The trigger resolved itself and the problem can still be observed.
# The trigger is still firing but the problem cannot be observed: Our triggers might not be perfect, so it could be that something else is causing it to fire. A simple example would be that Zabbix reports that the the DNS for a site can't be resolved, but in reality there's a bug in the script we wrote that checks if the DNS resolves and the DNS resolves fine. Final note: keep in mind that an 'it works on my machine' does not necessarily mean it works for most other people, so depening on the trigger you need to do some evaluations if your tests suffice.

In order to make sure you are actually trying to observe the same thing as the trigger is looking for, make sure to check the trigger definition and the current data of the associated item(s). Some triggers might fire if one of multiple conditions is met (Such as a trigger that monitors the ping response time firing if the value exceeds a certain threshold, or if no data for a certain period of time was observed).

Make sure to report your findings in the incident's thread. It's advised to post a screenshot of the relevant item(s) and your own observations. (Continuing the ping example, you would post a screenshot of the relevant values, state your conclusion why the trigger is firing, and your own observations/pings)

==== Communicate to affected clients ====
If the incident is still ongoing and the service is down, we need to communicate to affected clients that we are aware of the problem and that we are investigating it. This is because critical incident usually mean the service is down, something the clients can notice/are affected by, so we to be transparent that something is going on. There are some additional notes to this though:
* If an incident has already resolved itself and the problem is no longer observable, we don't communicate anything. Doing so might only cause confusion, and since the client has not reported any issues, they have not had a noticeable problem with it themselves.
* Although a critical incident generally means that the client service is down or experiencing reduced service, not all critical incidents are of that nature. Some are more administrative, or are only an issue for Delft Solutions itself. As of writing I don't have an exhaustive list, but here is those I can think of:
** SSH Service is down: We don't have any clients that SSH into their services, so it's generally not a problem. But SSH is mostly used for SRE maintenance and publishing new builds. The SRE maintenance is an internal problem, so no need to communicate to the client. The publishing is done to Kaboom, preventing new builds from being published, and the two SM VMs.
** No backup for x days: Clients don't notice it if a backup is running late, so no need to communicate with clients. Just need to make sure the backup gets completed
** SSL certificate is expiring in < 24 hours: This is a bit dependent on how soon this incident is being handled, but if it handled quickly, the certificate never actually expired, and there has not been any disruption to the client's service, so no need for communicating about it.
* Determining which clients are being affected can be done by looking at the host's DNS in the trigger, and/or looking up the VM in Proxmox and checking the tags of the VMs for client names. In the case that this issue is causing multiple other critical triggers to fire, you would have to check for which clients are affected by those incidents.
* Communicating to DS about ongoing incidents is usually assumed to be automatically have been done by the fact that the incident was reported on Zulip.

As always, report the decisions taken and actions made in the incident thread. (e.g.: I've sent a message in the Slack to let Kaboom know that we aware of problem x, and that we are investigating it)

==== Communicate plan/next steps + Communicate findings/results of executed plan ====
This is the main part of handling an incident. There are several actions you can take in these steps, but at the basis they consist of sharing your next steps, performing those, and reporting the results. The reason all this needs to be reported is to ensure that all known information about a problem is logged, making it easier for someone else to be onboarded into the issue, for later reference if a similar issue is encountered, and even for use during the incident itself in case an older configuration needs to be referenced after you changed it.
The objective from these steps is determining what is actually wrong and how to resolve it. Depending on the observations made earlier on whether the incident is still ongoing and is (still) observable your investigation can go into different directions. (e.g. Find the underlying cause for a trigger, or determining why the trigger is firing while it likely shouldn't, and then how to resolve that underlying cause or how to update the trigger to work better)

There are three main types of steps defined, but you are not limited to these:
# Hypothesis: If you have an idea what could be causing it, you would state your hypothesis and your next step would be to prove that hypothesis. For example, for an incident 'SSH service is down on X' your hypothesis could be that this is due to 'MaxStartups' throttling, which can be proven by 'grep'ing journalctl for that, and compare the start and end times of throttling with the timestamps of the item reporting the status of the SSH service.
# Information gathering: Sometimes it just helps to get some facts about the situation collected. What is usefull information that is relevant depends on the triggers, but some examples are: The syslog/journalctl of the host from around the time of the incident (it can contain a reference to the an underlying problem in various levels of explicitness), the ping response from several hosts on the route to a host or a traceroute (this helps with networking issues). The gathered information is usually intended to help you come up with an hypothesis on what's wrong.
# Investigative: The most rigorous of process. The full process is described here originally [https://docs.google.com/document/d/1AQYJM1Q9l2Tyk6zfCVaQ2aEq-dpbfUH5okE88bpKkhw/edit#heading=h.5fq2skijqbdc Drive - Final Coundown - General Investigative Process]. To summarize, when you don't know why something is failing, and/or don't have any decent hypotheses to follow up, you can follow this process to systematically find the problem.

Regarding the resolution to an incident: The resolution to any incident is usually one of two things:
# Fix the underlying problem.
# Fix the trigger itself.
Fixing the trigger is relatively straightforward, but do make sure document in the thread what you changed to which trigger.
Fixing the underlying problem can be more complex. A trade-off needs to be made sometimes between resolving technical debt, or simply patching the current system to resolve the issue. We usually look for a resolution that ensures that the problem won't re-occur soon, or makes it unexpected/unlikely for the problem to re-occur. Taking into account the time frame that is available to resolve the incident you can make some trade-offs. An example would be: normal backups of VMs are failing due to the Proxmox backup server being down/unreachable and it is determined that this cannot be resolved at that moment. We can set up automatic backups to local storage temporary to resolve the immediate problem and ensure we keep our SLO's versus setting up a new Proxmox Backup server at a different location. Since we don't have much time to resolve the problem, the resolution would be to set up the automatic backups to local storage, and set up a new Proxmox Backup Server later as a seperate issue.

===== Some known issues and their resolutions =====
* SSH service is down: The internet is a vile place. There's constant port scanning and hacking attempts ongoing to any machine connected to the internet (mostly IPv4). Due to this, SSH has a throttling functionality build in to prevent a system from being DDOS'ed by the amount of malicious SSH requests. This throttling can cause the Zabbix server from being denied an SSH connection, of which several failures fire this trigger. This hypothesis can be proven with a `journalctl -u ssh | grep 'MaxStartups throttling'` (you probably want to select a relevant time period with `--since "2 hours ago"` or something similar to prevent having to process a month of logging). You can then compare the throttling start and end times with the timestamps of the item data itself. The resolution for the issue is to add our custom ssh configuration [https://chat.dsinternal.net/#narrow/stream/23-SRE---General/topic/DS.20Whitelisted.20Custom.20SSH.20configuration/near/1620 Custom SSH Configuration].
* No backup for 3 days: Are S3 backup is very slow. Not much to prove as an underlying issue here. What needs to be done is check that the backup process is ongoing. The Zabbix latest data can be checked to verify that backups are running by checking that that days backups were done for the smaller buckets. The devteam email can be checked for if the backup process could not start on day due to it already running (it takes 24+ hours, and an attempt to start it is done each day by cron).
* git.* HTTPS is down: On Sunday mostly, Gitlab gets automatically updated, but this incurs some downtime as the service is restarted. This is usually short enough to not be reported to Zulip as per our settings, but sometimes it's longer. If the service does not stay down, the issue can be just resolved.

==== Resolve incident + cleanup ====
When you've executed and verified the resolution in the previous steps we can proceed resolving the issue in our Mattermost integration. Resolving an incident can be done by doing the following:
# Verify that the trigger is no longer firing. An incident will be immediately re-opened if the trigger is still firing, and the incident cannot be considered resolved if the trigger is still firing. If the trigger is still firing but you're sure that you've resolved the problem, you might need to force the item the trigger depends on to update. This can be done by finding the item in the host's configuration on Zabbix and selecting 'Execute Now', after a short period this should force Zabbix to re-execute the item. You can check the timestamps in the latest data of an item to check if it was updated.
# Close the incident by marking the topic as resolved, when there are no other triggers firing for the host.

Unfortunately, some problems cause multiple critical and non-critical triggers to fire. This means we have to check Zabbix and Zulip for other fired triggers and ongoing incidents. The goal is to identify critical and non-critical incidents that were caused by the incident/underlying issue you just resolved.
# First, these incidents need to be acknowledged on Zabbix, and in the acknowledgement message you mention the incident/problem that caused this.
# Next, check the incident tracked by the integration on Mattermost using the `?ongoing` command. Resolve incidents that were (re-)opened by this incident by executing the following steps. If the first two fail (problem still persists, trigger is still firing), the incident needs to considered it's own issue and the relevant process needs to be followed (critical or non-critical depending on criticality).
## Ensuring the mentioned problem is no longer observable
## The trigger has resolved (You might need to force an update with `Execute Now`).
## Posting a link to the main incident you resolved with the comment that the underlying problem was resolved in that topic.
## Closing the incident by marking the topic as resolved, when there are no other triggers firing for the host.

When you are done, there should be no more critical triggers firing in Zabbix or open in the Zabbix-Mattermost integration, for which no-one has taken responsibility or you have taken responsibility for and are not actively handling.

== Non-Critical incidents ==
* Non-critical incidents are acknowledged within 9 hours and resolved within one week.

=== Acknowledging ===
Fully acknowledging a non-critical incident requires the following tasks to have been completed:
* Acknowledging the incident on Zabbix, which means you take responsibility of completing the steps listed below.

The next steps don't have to be done immediately, as they have dependencies, but be started and scheduled for completion the next work day.

Check if there's already a uncompleted milestone for this host with this issue in the metrics sheet.
If a milestone is already present:
* Report in the topic the Lynx project ID for resolving this issue.
* If the ID has already been reported in the topic, we don't want to report it again and again, instead add the 🔁 emoji (:repeat:) under the zabbix bot alert

If a milestone is NOT already present:
* Add the non-critical incident as a milestone in the metrics sheet, following the naming convention
** Start date is the date of the incident
** DoD states what needs to be true for the non-critical incident to be consider resolved
* Add the non-critical incident to Lynx as a project
** Follow the naming convention below for the title & project ID
** Tasks need to be added
** Final tasks needs to have the SLO deadline set as 'constraint'
** Project priority is set to 99 while not estimated yet. After the estimation is done, the priority should be set to 20
** The tasks are estimated for SP
* The Lynx project ID is reported in the non-critical incident's topic on Zulip, and logged in the metrics sheet
* A Kimai activity is created in Kimai for the non-critical incident, following the naming convetion

==== Naming convention ====
* Kimai activity name needs to follow the pattern: '<YYYY-MM> <problem_title>'. For <problem_title>, incorporate the trigger title and hostname for clarity.
* Milestone name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project ID needs to follow the pattern: 'SRE<YYMM><XXX>', where <XXX> is some three letter shorthand that relates to the problem/host

== Informational incidents ==
* Informational incidents are acknowledged within 72 hours

Checklist
# Acknowledge on Zabbix
# Sanity check the event, post result in thread
# If action needed, perform action

== If an incident is reported by other means than the Zabbix-Zulip integration ==
Besides the automated Zabbix-Zulip integration, incidents can also be reported through emails from cron jobs, direct emails from customers, or topics in SRE General (such as alerts about Zulip updates or issues raised by colleagues), etc.
# Acknowledge receipt.
# Classify the incident as critical, non-critical, or informational.
# Create an topic in the relevant SRE channel, stating the problem and that you is responsible for resolving it.
# Proceed to treat the incident according to the criticality you just classified it as. (So for a critical incident, it means you now start the critical incident handling process)

== Handover ==
See [[Handover]]

Incident Handling

2025-10-21T11:09:52Z

Jakobbuis:

= This is the process =
This document is an authoritative description of the process. This document supersedes all prior documents on the process.

= Deviating from the process =
You may deviate from the process at any moment. A deviation should be communicated to the dev-team, preferably in the Zulip topic about the applicable incident, ideally as soon as possible after deciding to deviate.

= Checklist =
This checklist is a shorter, imperative version of [[Incident Handling#Full_procedure|the longer procedure below]]. You're encouraged to read the [[Incident Handling#Full_procedure|full procedure]] at least once to improve your understanding of the core material.

=== Critical Incidents ===
Critical incidents must be resolved within 16 hours.

# Acknowledge trigger in Zabbix.
# Check if the incident is still ongoing.
# Determine whether the incident is ongoing
# Determine whether clients are potentially affected, if so:
## notify the affected clients (Slack preferred)
## share the message sent to the client in the incident Zulip thread
# Document all actions taken in the Zulip topic.
# Create a plan of action.
# Execute plan and document results in Zabbix thread.
# If unresolved, create a new plan.
# When resolved:
## Verify trigger is no longer firing.
## Decide on when to notify affected clients (that you have notified of the incident), the incident has been resolved, and communicate this internally
## Mark Zulip topic as resolved if no other incidents for the host.
## Check for related triggers and resolve them.

Common issues that have occurred previously, and ''could'' occur again:
* SSH down: Check MaxStartups throttling, apply custom SSH config
* No backup: Verify backup process is running, check the devteam email
* HTTPS down on Sunday: this can be due to GitLab updates

=== Non-Critical Incidents ===
Non-critical incidents must be acknowledged within 9 hours and resolved within 1 week.

# Acknowledge in Zabbix thread
# Check metrics sheet for existing milestone
## If a milestone exists:
### Add Lynx project ID to Zulip topic
### Add 🔁 emoji if ID already reported
## If no milestone exists:
### Add to metrics sheet
### Create Lynx project (priority 99, then 20 after estimation)
### Create Kimai activity
### Document IDs in Zulip topic

=== Informational Incidents ===
Informational incidents must be acknowledged within 72 hours.

# Acknowledge in Zabbix
# Verify issue
# Take action if needed

=== External Reports ===

# Acknowledge receipt
# Classify report as critical, non-critical or informational.
# Create a Zulip topic in SRE # Critical, SRE ## Non-critical or SRE ### Informational (depending on classification) and add sufficient details.
# Proceed with checklist above for the type of incident.

= Full procedure =

== General Rules ==

# When an incident is in progress, and person A is handling it, then all incidents in area X, are handled by person A, rather than the FR. Unless working day ends. Person A should communicate clearly to FR when their day is over.
# FR always has the last word on what solution to apply for resolving an incident.

== Critical incidents ==
'''Critical incidents are resolved within 16 hours.'''

As first responder you take on the responsiblity of seeing an incident resolved. This does not mean that you are the person required to do all the work. You can attempt to involve others to help you (often referred to as escalating the incident), but since other are not on-call, they are not obliged to help you, especially outside of normal working hours.
Involving multiple people can quickly be required if multiple critical incidents with different causes occur simultaneously. In that case, the First Responder usually takes on a more information management role and steers those that are brought on into resolving the issues. (Example: if a server crashes, several critical triggers can fire, but the underlying cause can quite quickly be determined to be a single issue, the crashed server. So you wouldn't need to call in people to manage each incident. But a client's service being down in one cluster while in a different cluster a different VM no longer boots is likely to be to different issues, so in order to resolve them on time you'd want to call in help to resolve the incident in time).

=== Process ===
The general process is made up of the following steps. Each step has additional information on how to handle/execute them in the sections below.
# Take responsibility for seeing the incident resolved
# Determine if incident is still ongoing
# If ongoing: Communicate to affected clients that the issue is being investigated
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# Resolve incident + cleanup

During working on an incident it is expected that all communication is done in the incident's thread. This means all information to a problem can be found in a clear a predictable place. Sometimes an incident can be resolved by work done in another incident. In that case, it is required to post a link to that thread in the incident's thread with the comment that the resolution is done in that thread.

==== Acknowledge the incident on Zabbix ====
The first step is to take responsibility for seeing the incident resolved by acknowledging the incident on Zabbix. Simply acknowledging the trigger suffices. It is however entirely possible that multiple critical incidents are firing at the same time. This can be a coincidence, or can be because of a share cause of failure. For example, a server crashing will cause server VMs to reboot, or the router having an connectivity issue will lead to most other VMs having connectivity issues as well. If there are multiple critical incidents, it is advised to quickly observe what's ongoing, Zabbix is the best source of firing triggers for this, and pick the incident that is likely the root cause to

* Acknowledging an incident on Zabbix will stop Zabbix from calling the First Responder to notify them of the ongoing incident. And stops Zabbix from posting reminders on Zulip.

==== Determine if incident is still ongoing ====
The next step is to check if the reported problem is still ongoing. Depending on the observations made here your process to follow and steps needed to resolve the incident can change. There are three options:
# The trigger resolved itself and the problem cannot be observed. Example: HTTPS is down for a site, but the FR can access the site through HTTPS without incident.
# The trigger resolved itself and the problem can still be observed.
# The trigger is still firing but the problem cannot be observed: Our triggers might not be perfect, so it could be that something else is causing it to fire. A simple example would be that Zabbix reports that the the DNS for a site can't be resolved, but in reality there's a bug in the script we wrote that checks if the DNS resolves and the DNS resolves fine. Final note: keep in mind that an 'it works on my machine' does not necessarily mean it works for most other people, so depening on the trigger you need to do some evaluations if your tests suffice.

In order to make sure you are actually trying to observe the same thing as the trigger is looking for, make sure to check the trigger definition and the current data of the associated item(s). Some triggers might fire if one of multiple conditions is met (Such as a trigger that monitors the ping response time firing if the value exceeds a certain threshold, or if no data for a certain period of time was observed).

Make sure to report your findings in the incident's thread. It's advised to post a screenshot of the relevant item(s) and your own observations. (Continuing the ping example, you would post a screenshot of the relevant values, state your conclusion why the trigger is firing, and your own observations/pings)

==== Communicate to affected clients ====
If the incident is still ongoing and the service is down, we need to communicate to affected clients that we are aware of the problem and that we are investigating it. This is because critical incident usually mean the service is down, something the clients can notice/are affected by, so we to be transparent that something is going on. There are some additional notes to this though:
* If an incident has already resolved itself and the problem is no longer observable, we don't communicate anything. Doing so might only cause confusion, and since the client has not reported any issues, they have not had a noticeable problem with it themselves.
* Although a critical incident generally means that the client service is down or experiencing reduced service, not all critical incidents are of that nature. Some are more administrative, or are only an issue for Delft Solutions itself. As of writing I don't have an exhaustive list, but here is those I can think of:
** SSH Service is down: We don't have any clients that SSH into their services, so it's generally not a problem. But SSH is mostly used for SRE maintenance and publishing new builds. The SRE maintenance is an internal problem, so no need to communicate to the client. The publishing is done to Kaboom, preventing new builds from being published, and the two SM VMs.
** No backup for x days: Clients don't notice it if a backup is running late, so no need to communicate with clients. Just need to make sure the backup gets completed
** SSL certificate is expiring in < 24 hours: This is a bit dependent on how soon this incident is being handled, but if it handled quickly, the certificate never actually expired, and there has not been any disruption to the client's service, so no need for communicating about it.
* Determining which clients are being affected can be done by looking at the host's DNS in the trigger, and/or looking up the VM in Proxmox and checking the tags of the VMs for client names. In the case that this issue is causing multiple other critical triggers to fire, you would have to check for which clients are affected by those incidents.
* Communicating to DS about ongoing incidents is usually assumed to be automatically have been done by the fact that the incident was reported on Zulip.

As always, report the decisions taken and actions made in the incident thread. (e.g.: I've sent a message in the Slack to let Kaboom know that we aware of problem x, and that we are investigating it)

==== Communicate plan/next steps + Communicate findings/results of executed plan ====
This is the main part of handling an incident. There are several actions you can take in these steps, but at the basis they consist of sharing your next steps, performing those, and reporting the results. The reason all this needs to be reported is to ensure that all known information about a problem is logged, making it easier for someone else to be onboarded into the issue, for later reference if a similar issue is encountered, and even for use during the incident itself in case an older configuration needs to be referenced after you changed it.
The objective from these steps is determining what is actually wrong and how to resolve it. Depending on the observations made earlier on whether the incident is still ongoing and is (still) observable your investigation can go into different directions. (e.g. Find the underlying cause for a trigger, or determining why the trigger is firing while it likely shouldn't, and then how to resolve that underlying cause or how to update the trigger to work better)

There are three main types of steps defined, but you are not limited to these:
# Hypothesis: If you have an idea what could be causing it, you would state your hypothesis and your next step would be to prove that hypothesis. For example, for an incident 'SSH service is down on X' your hypothesis could be that this is due to 'MaxStartups' throttling, which can be proven by 'grep'ing journalctl for that, and compare the start and end times of throttling with the timestamps of the item reporting the status of the SSH service.
# Information gathering: Sometimes it just helps to get some facts about the situation collected. What is usefull information that is relevant depends on the triggers, but some examples are: The syslog/journalctl of the host from around the time of the incident (it can contain a reference to the an underlying problem in various levels of explicitness), the ping response from several hosts on the route to a host or a traceroute (this helps with networking issues). The gathered information is usually intended to help you come up with an hypothesis on what's wrong.
# Investigative: The most rigorous of process. The full process is described here originally [https://docs.google.com/document/d/1AQYJM1Q9l2Tyk6zfCVaQ2aEq-dpbfUH5okE88bpKkhw/edit#heading=h.5fq2skijqbdc Drive - Final Coundown - General Investigative Process]. To summarize, when you don't know why something is failing, and/or don't have any decent hypotheses to follow up, you can follow this process to systematically find the problem.

Regarding the resolution to an incident: The resolution to any incident is usually one of two things:
# Fix the underlying problem.
# Fix the trigger itself.
Fixing the trigger is relatively straightforward, but do make sure document in the thread what you changed to which trigger.
Fixing the underlying problem can be more complex. A trade-off needs to be made sometimes between resolving technical debt, or simply patching the current system to resolve the issue. We usually look for a resolution that ensures that the problem won't re-occur soon, or makes it unexpected/unlikely for the problem to re-occur. Taking into account the time frame that is available to resolve the incident you can make some trade-offs. An example would be: normal backups of VMs are failing due to the Proxmox backup server being down/unreachable and it is determined that this cannot be resolved at that moment. We can set up automatic backups to local storage temporary to resolve the immediate problem and ensure we keep our SLO's versus setting up a new Proxmox Backup server at a different location. Since we don't have much time to resolve the problem, the resolution would be to set up the automatic backups to local storage, and set up a new Proxmox Backup Server later as a seperate issue.

===== Some known issues and their resolutions =====
* SSH service is down: The internet is a vile place. There's constant port scanning and hacking attempts ongoing to any machine connected to the internet (mostly IPv4). Due to this, SSH has a throttling functionality build in to prevent a system from being DDOS'ed by the amount of malicious SSH requests. This throttling can cause the Zabbix server from being denied an SSH connection, of which several failures fire this trigger. This hypothesis can be proven with a `journalctl -u ssh | grep 'MaxStartups throttling'` (you probably want to select a relevant time period with `--since "2 hours ago"` or something similar to prevent having to process a month of logging). You can then compare the throttling start and end times with the timestamps of the item data itself. The resolution for the issue is to add our custom ssh configuration [https://chat.dsinternal.net/#narrow/stream/23-SRE---General/topic/DS.20Whitelisted.20Custom.20SSH.20configuration/near/1620 Custom SSH Configuration].
* No backup for 3 days: Are S3 backup is very slow. Not much to prove as an underlying issue here. What needs to be done is check that the backup process is ongoing. The Zabbix latest data can be checked to verify that backups are running by checking that that days backups were done for the smaller buckets. The devteam email can be checked for if the backup process could not start on day due to it already running (it takes 24+ hours, and an attempt to start it is done each day by cron).
* git.* HTTPS is down: On Sunday mostly, Gitlab gets automatically updated, but this incurs some downtime as the service is restarted. This is usually short enough to not be reported to Zulip as per our settings, but sometimes it's longer. If the service does not stay down, the issue can be just resolved.

==== Resolve incident + cleanup ====
When you've executed and verified the resolution in the previous steps we can proceed resolving the issue in our Mattermost integration. Resolving an incident can be done by doing the following:
# Verify that the trigger is no longer firing. An incident will be immediately re-opened if the trigger is still firing, and the incident cannot be considered resolved if the trigger is still firing. If the trigger is still firing but you're sure that you've resolved the problem, you might need to force the item the trigger depends on to update. This can be done by finding the item in the host's configuration on Zabbix and selecting 'Execute Now', after a short period this should force Zabbix to re-execute the item. You can check the timestamps in the latest data of an item to check if it was updated.
# Close the incident by marking the topic as resolved, when there are no other triggers firing for the host.

Unfortunately, some problems cause multiple critical and non-critical triggers to fire. This means we have to check Zabbix and Zulip for other fired triggers and ongoing incidents. The goal is to identify critical and non-critical incidents that were caused by the incident/underlying issue you just resolved.
# First, these incidents need to be acknowledged on Zabbix, and in the acknowledgement message you mention the incident/problem that caused this.
# Next, check the incident tracked by the integration on Mattermost using the `?ongoing` command. Resolve incidents that were (re-)opened by this incident by executing the following steps. If the first two fail (problem still persists, trigger is still firing), the incident needs to considered it's own issue and the relevant process needs to be followed (critical or non-critical depending on criticality).
## Ensuring the mentioned problem is no longer observable
## The trigger has resolved (You might need to force an update with `Execute Now`).
## Posting a link to the main incident you resolved with the comment that the underlying problem was resolved in that topic.
## Closing the incident by marking the topic as resolved, when there are no other triggers firing for the host.

When you are done, there should be no more critical triggers firing in Zabbix or open in the Zabbix-Mattermost integration, for which no-one has taken responsibility or you have taken responsibility for and are not actively handling.

== Non-Critical incidents ==
* Non-critical incidents are acknowledged within 9 hours and resolved within one week.

=== Acknowledging ===
Fully acknowledging a non-critical incident requires the following tasks to have been completed:
* Acknowledging the incident on Zabbix, which means you take responsibility of completing the steps listed below.

The next steps don't have to be done immediately, as they have dependencies, but be started and scheduled for completion the next work day.

Check if there's already a uncompleted milestone for this host with this issue in the metrics sheet.
If a milestone is already present:
* Report in the topic the Lynx project ID for resolving this issue.
* If the ID has already been reported in the topic, we don't want to report it again and again, instead add the 🔁 emoji (:repeat:) under the zabbix bot alert

If a milestone is NOT already present:
* Add the non-critical incident as a milestone in the metrics sheet, following the naming convention
** Start date is the date of the incident
** DoD states what needs to be true for the non-critical incident to be consider resolved
* Add the non-critical incident to Lynx as a project
** Follow the naming convention below for the title & project ID
** Tasks need to be added
** Final tasks needs to have the SLO deadline set as 'constraint'
** Project priority is set to 99 while not estimated yet. After the estimation is done, the priority should be set to 20
** The tasks are estimated for SP
* The Lynx project ID is reported in the non-critical incident's topic on Zulip, and logged in the metrics sheet
* A Kimai activity is created in Kimai for the non-critical incident, following the naming convetion

==== Naming convention ====
* Kimai activity name needs to follow the pattern: '<YYYY-MM> <problem_title>'. For <problem_title>, incorporate the trigger title and hostname for clarity.
* Milestone name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project ID needs to follow the pattern: 'SRE<YYMM><XXX>', where <XXX> is some three letter shorthand that relates to the problem/host

== Informational incidents ==
* Informational incidents are acknowledged within 72 hours

Checklist
# Acknowledge on Zabbix
# Sanity check the event, post result in thread
# If action needed, perform action

== If an incident is reported by other means than the Zabbix-Zulip integration ==
Besides the automated Zabbix-Zulip integration, incidents can also be reported through emails from cron jobs, direct emails from customers, or topics in SRE General (such as alerts about Zulip updates or issues raised by colleagues), etc.
# Acknowledge receipt.
# Classify the incident as critical, non-critical, or informational.
# Create an topic in the relevant SRE channel, stating the problem and that you is responsible for resolving it.
# Proceed to treat the incident according to the criticality you just classified it as. (So for a critical incident, it means you now start the critical incident handling process)

== Handover ==
See [[Handover]]