If you frequently have incidents and other pop-up work that needs to be prioritized, Scrum probably isn't a good fit. The core of Scrum is the Sprint. If you can't consistently hold a planning session to select a goal and work that supports that goal for the Sprint, execute the work, synchronize with stakeholders, and then improve your way of working on that Sprint cadence, you're going to struggle with Scrum.
The rest of your context isn't well-suited to Scrum, either.
Scrum is built around a team supporting a single product, yet your team is supporting 3. If you were to "do Scrum", you would have three Product Owners and three Product Backlogs. Even if you were to have fewer Product Owners, you should still have three Product Backlogs. However, the team would struggle to focus on a cohesive goal for the Sprint unless each Sprint can be dedicated to a single product. This is especially true if the products are all operational and need ongoing monitoring and potential support for incidents.
The team size is also on the small side for a formal methodology. Unless the manager is actively developing the product as well, you only have two developers. The Scrum framework is designed to coordinate the work among a team, so some of the activities described in the Scrum framework will probably be excessive or even add additional overhead rather than making the team's life easier.
The best course of action would be to look outside of Scrum since the practices there aren't suited to your current context. However, if you are stuck in Scrum, you still have options.
All work that is done in the Sprint must be visible. If there are incidents, they need to be in your Sprint Backlog, on your Sprint Board, and everyone needs to be aware that these incidents came up. When you get to the Sprint Review and Sprint Retrospective, the team needs to communicate the impact of these incidents. At the Sprint Review, should be able to explain the issues that came up and how those impacted the team's ability to achieve the Sprint Goal.
Going forward, the Sprint Planning session should include incidents when considering capacity. If your organization embraces DevOps, you should have extensive monitoring of applications that can provide information about incidents. Using past performance on how long it takes to resolve an incident, the team needs to set aside time and not plan their Sprint to capacity. The Sprint Goal should be generally achievable, considering a "normal" amount of incidents and time to resolve those incidents across the supported systems.
At an organizational level, there needs to be a strong effort to address the incidents' root causes. By reducing the number of incidents or developing ways to restore the system to a normal operating state faster, the team's capacity for development will increase.