# Ongoing support for your production systems from engineers who know them. > Managed application support for production systems: monitoring, patching, bug fixes, on-call and small changes, with service levels set per contract. Source: https://www.algofact.tech/en/services/cloud/managed-it-support Language: en-US Updated: 2026-10-26 Languages: en-US, tr-TR ALGOFACT provides managed support for the applications it built or took over after a technical review, and for the infrastructure they run on: monitoring and alerting, security patching, bug fixes, backup checks, capacity tracking and small enhancements. Service levels, working hours and on-call coverage are written into each contract according to how critical the system is. Support is delivered by an embedded team of engineers who know the system, working from our offices in Adana and Ankara TEKMER, Türkiye. ## Key facts - **Scope:** Applications, databases and cloud infrastructure - **Systems covered:** Built by ALGOFACT or taken over after review - **Service levels:** Set per contract by system criticality - **Model:** Embedded team that knows the system - **Reporting:** Periodic incident and change reports - **Information security:** ISO 27001:2022 access and change management ## When is managed support the right model? Much of the work on a system starts after it goes live: security patches, certificate renewals, disks filling up, queries slowing down, integrations changing and bug reports from users. Building a full-time team for that is not sensible for every company, and handing it to a help desk that has never seen the system makes every problem last longer. Managed support means the engineers who built the system, or who learned it through a structured takeover, keep running it. Knowledge lives in runbooks and records rather than in people’s heads, so support continues even when the team changes. Our focus is applications and the infrastructure under them. Desktop IT, such as office networks, end-user laptops or printers, is not the center of this service; if you need it, we discuss it separately in the discovery call. ## What support covers Scope is written per system; most agreements combine these tasks. ### Monitoring and alerting Application, database and infrastructure metrics, error rates and business-critical flows such as payments, sign-in or integrations are monitored, and alerts are routed to the on-call engineer. ### Patching and version upkeep Operating system, runtime, library and database updates are tried in a test environment first and applied in planned maintenance windows. ### Bug fixing Issues from users or monitoring are prioritized, traced to their root cause, fixed, tested, released and recorded in the incident log. ### Backup and restore checks We do not assume backups work. Regular test restores confirm that backups can actually be used. ### Capacity and cost tracking Data growth, traffic and the cloud bill are watched, and we propose action before a bottleneck or wasted spend appears. ### Small enhancements Requests such as a screen, report or integration change are scheduled within the development capacity set aside in the contract. ## Takeover and operations ### Takeover review If another team built the system, we first review the code, infrastructure, access, documentation and open bugs. Fixes needed to make it supportable are planned as a separate onboarding job. ### Access and knowledge transfer Access is tied to roles rather than individuals, critical knowledge is written into runbooks and missing monitoring is put in place. ### Writing the service levels Priority classes, working hours, on-call coverage, communication channels and reporting are defined together in the contract. ### Day-to-day operations Incidents, changes and maintenance are tracked in a ticketing system. After every serious incident, the root cause and a preventive step are written down. ### Regular reviews Incident trends, open risks, capacity and the roadmap are reviewed with you in regular meetings. ## What you receive ### Service level definition Priority classes, scope, working hours and on-call rotation. ### Monitoring and on-call setup Health indicators, alert thresholds and how an alert reaches the on-call engineer. ### Support runbooks Step-by-step procedures for common incidents, maintenance tasks and restores. ### Incident and change records A timeline, root cause and fix for every incident; approval and outcome for every change. ### Periodic status report Incidents, maintenance done, open risks and recommended improvements. ## How service levels are set We do not promise a response time on this page, because the right target depends on the system. A system that holds patient records or takes payments does not need the same on-call setup as an internal reporting tool used a few times a month. The contract spells out, per system, the priority classes, working hours, whether there is after-hours on-call and the communication channels. The systems on ALGOFACT’s /work page include software that is expected to run without interruption, such as family health center management software for the Turkish Ministry of Health (Sağlık Bakanlığı), hospital management system software for Letoon and a membership dues collection system for KAFFED. In the systems we build, monitoring, logging and runbooks are ready before go-live, which makes later support easier to plan. Access, change approval and record keeping follow our ISO 27001:2022 certified information security management system. On systems that hold personal data, engineers’ access to that data is limited to what their task requires and is logged. ## Questions about managed support ### Will you take over a system another vendor built? Yes, after a takeover review. We examine the code, infrastructure, access and documentation and present in writing what is needed to make the system supportable. In some cases we recommend a substantial cleanup before support begins. ### What are your response times? Response and resolution targets are agreed in the contract based on how critical the system is. Rather than quote a general figure, we write down what happens within which time for each priority class. ### Do you offer after-hours and weekend coverage? For systems that need it, an after-hours on-call rotation can be added to the contract. Which systems and which priority classes it covers is defined explicitly. ### Is the support team the same as the development team? As far as possible, yes. The engineers who built the system take part in support, which makes it easier to get to the root cause of a bug. When the team changes, knowledge passes through runbooks and incident records. ### What drives the cost of a support agreement? The number and complexity of the systems, the working hours and on-call coverage you need, the development capacity set aside, where the infrastructure runs and the state of the system before takeover. After the review we present the scope and service level options in writing. ### What happens to the system when the contract ends? The system and all access belong to you. Because runbooks, incident records and documentation are kept current, the handover to your own team or another vendor can be planned. ## Related - [Cloud](https://www.algofact.tech/en/services/cloud) - [DevOps and CI/CD](https://www.algofact.tech/en/services/cloud/devops) - [Software and cloud security](https://www.algofact.tech/en/services/cloud/cybersecurity) - [Use cases](https://www.algofact.tech/en/work) - [Discovery call](https://www.algofact.tech/en/contact)