Linux Server Support FAQs

We agree who owns each part of your environment, so your people know where Tiger’s responsibility starts and how we’ll work together. Most often, your team manages the application and Tiger manages the Linux platform it runs on.

Your developers tell us what the application needs, and we provide the platform information they need to investigate problems on their side. Each managed part has one owner, avoiding conflicting changes while keeping the teams working closely together.

We’ll discuss that boundary with you before support begins, including how changes are requested, approved and coordinated.

We typically support software supplied with your Linux distribution and assess other open-source applications individually. We’ll agree which components are covered before support begins.

Commercial applications normally remain supported by their software vendor, and custom applications or websites remain with their developers. We’re happy to work with those teams, supporting the agreed Linux platform and sharing information to help them investigate problems.

That gives you specialist Linux expertise alongside the people who know your application, with a clear responsibility split.

Possibly. We assess older systems individually and would prefer to help you move to a maintained release where practical.

If we accept an older version onto support, a surcharge applies. Resolving faults caused by its unsupported status may also be chargeable. We’ll explain the options and limitations for your systems before you commit, so you can weigh the immediate need against a longer-term upgrade.

We support Linux on physical servers, virtual machines and cloud instances. On physical servers, we look after the operating system and agreed software rather than carrying out hardware repairs.

We usually monitor hardware health, alert you when something is failing and liaise with your hardware supplier or maintenance provider. Repairs and replacement parts remain their responsibility.

The Pre-Contract Check helps us understand systems we didn’t build before taking responsibility for their support. It is a chargeable inspection carried out under our Master Services Agreement, which includes mutual confidentiality provisions.

We establish what each system does, how it is configured and whether any work is needed before support can begin. We make no changes during the inspection.

You receive a confirmed proposal setting out the recommended support and any prerequisite work, including its cost or confirmation that it is included. Work we consider essential must be completed before the system comes onto support.

Start by telling us when your existing contract ends and how much notice it requires. This helps us plan the handover around your deadline.

We need authorised administrative access, a list of systems and their purpose, available documentation, known problems and work in progress. It helps if the outgoing provider can speak directly with our engineers.

We also check which monitoring agents, backup tools and management software are already installed, so existing arrangements aren’t removed before replacements are working. If your provider is unable to help, we can still discuss taking over provided you can give us authorised access, although the process may take longer.

Yes. Contact us whether they are preparing to leave or have already gone. We’ll help you establish what needs attention and what access is available.

An organised handover before departure usually saves investigation later. Useful information includes what each system does, how it is backed up, scheduled tasks and known problems.

If the administrator has already left, we need authorised access first. Where access has been lost, we can assess legitimate recovery routes through the server console or hosting provider. We can then agree immediate help where needed and plan ongoing support.

It depends on your environment. We have brought customers fully onto support within a few days of signing, but complex arrangements can take several months.

The main factors are access, the number of systems, any essential remedial work and when changes can be made. Having someone available to answer questions and approve changes helps things progress.

Tell us about your deadline early. We’ll explain what is achievable and distinguish the agreed support start date from completion of the monitoring and management setup.

In some circumstances, yes. Essential remedial work must be completed first, and we need a signed support schedule and access to your systems.

Monitoring and configuration management may still be getting established when an agreed support period begins. Until those tools are operational, support is reactive and on a best-efforts basis: we can respond to problems you report, but cannot yet detect them through our monitoring.

We agree any known outstanding problems with you in writing. Resolving faults they cause may be chargeable. If you need help before ongoing support arrangements are settled, we can discuss emergency support or consultancy.

Onboarding normally involves installing our monitoring and configuration management software, setting up engineer access and arranging the required network connections. Those steps do not normally interrupt service.

Before making changes, we capture the system configuration and installed software list. Our configuration management initially runs in report-only mode, showing what it would change without applying it. An engineer reviews the results, and we explain the proposed changes and obtain your approval. A second engineer checks each system before onboarding is complete.

Each system is normally restarted once to confirm it starts cleanly and runs the current kernel. We schedule that with you. Older systems or prerequisite remedial work may require additional maintenance windows.

Monitoring checks your systems for potential problems. Engineer response is the investigation and action taken when an issue needs attention.

We monitor supported systems 24/7, while engineer response follows your agreed support hours. Continuous monitoring therefore does not automatically mean round-the-clock engineer response.

Tell us when a failure would affect your organisation – including overnight processing or weekend operations – so we can discuss suitable cover.

No. A response target concerns responding to an incident; it is not a guaranteed restoration or resolution time. Priorities and response commitments are defined in your applicable agreement.

The time needed to restore service depends on the fault and the systems involved. Where continuity is especially important, we can also discuss fault-tolerant architecture to help services keep running when components fail. That is a separate consideration from the support response commitment.

Out-of-hours support requires a phone call under your agreed cover. Email is not an out-of-hours contact route.

We explain contact and escalation arrangements during handover, so your team knows how to raise an urgent issue. Premier Support customers also have an alert facility in TigerEye that can notify the on-call engineer.

We hold a first review about a month after your systems come onto support and at least annually afterwards. Some customers meet with us monthly.

We agree the frequency around how actively you want to work together. Reviews are an opportunity to discuss risks, changing requirements and recommended improvements. Where proposed work falls outside support, we explain it and provide a separate quote.

TigerEye is our online client portal. It gives you access to ticketing, summarised system-utilisation statistics and your support schedule, including the systems covered and your contacts.

Premier Support customers can also raise an alert through TigerEye and, where necessary, wake the on-call engineer.

It gives your team a practical place to follow support and understand the arrangement in place. We explain the functions relevant to your service during handover.

A configuration backup records how a system is set up, helping us rebuild that setup if needed. It does not include your files, databases or other data created by users and applications.

Configuration backup is included in support. Data backup is a separate service, using our geographically redundant backup systems or agreed third-party tools and storage.

We agree the data covered, storage, retention and quota. Our monitoring checks that backups complete, and we notify you before you reach your quota. If you do not take our data-backup service, backing up your data remains your responsibility.

Recovery testing is important: a completed backup does not prove that every restore will succeed.

Agree with us what should be tested, how often and who will check the results. You should also understand which data is protected, how long copies are retained and where they are stored.

If you need data restored, we do our best to recover it from the available backups. Restores may be chargeable, and no backup system can guarantee that every recovery will succeed.

By default, we apply security updates as soon as they are available. For clients on Business and Premier Support plans, we normally apply them outside business hours to reduce disruption. A different timing or schedule can be agreed.

We track security advisories and monitor whether supported systems are falling behind on updates.

Major operating system release upgrades are planned with you rather than applied automatically. In-place upgrades for certain distributions, including Debian and Ubuntu, are included in support. Other upgrades or migrations may need separately agreed work.

Wherever possible, we make changes through configuration management and version control, providing a record of what changed, when and why.

Significant changes are tested and reviewed by a second engineer, with the rollout agreed with you. Changes made manually are recorded against the relevant support ticket.

We agree how to work with your team and do not begin chargeable work without written approval. This gives you visibility over changes and their cost while allowing our engineers to manage the agreed platform.

Support focuses on keeping your agreed systems running and secure. It includes monitoring, security updates, configuration management, configuration backup and investigation of faults in software supplied with your Linux distribution. In-place operating system upgrades are included for certain distributions.

Some small changes are handled within support at our discretion. Larger work – such as building new services, migrations or significant reconfiguration – is generally consultancy and quoted separately.

Data backup is a separate service. Data restores, site visits, work requested outside your support hours, and faults caused by unagreed changes or unmaintained software may also be chargeable.

We do not start chargeable work without written approval. Where possible, we quote a fixed price for an agreed piece of work, so you know the cost before committing.

The main factors are how many systems you have, the support level each needs and their complexity. Different systems can be on different support levels, and larger estates attract volume discounts.

Other costs can include the Pre-Contract Check, prerequisite remedial work, a surcharge for unmaintained operating systems and separately priced data backup. Security or compliance requirements affect the price where they add work.

Our Linux Support Pricing Guide sets out current indicative plan prices and other charges. Your proposal confirms the scope and price for your environment.

Our Master Services Agreement sets out the terms of working together, including mutual confidentiality provisions. Each service is described in a schedule covering the systems, support levels, price and any minimum term.

We can provide a proposal before you sign the agreement, but we do not access your systems until it is in place.

Before committing, ask us to explain the notice periods, any minimum term and how to change your systems or support cover. Your signed agreement and schedules govern those arrangements.

We confirm when support ends and continue supporting your systems until that date. As part of offboarding, we remove our monitoring and management components and our access, leaving your systems configured to keep working without our management.

We securely return the passwords and access details we hold for your systems and confirm you have received them.

Our internal documentation and management tools remain with Tiger. Documentation delivered to you through a project remains yours. If you need assistance handing over to your team or another provider, we can provide it as consultancy.

Before support ends, we agree the treatment of backups and personal data under the applicable terms, so your retention and recovery requirements are understood.

Tiger is certified to ISO/IEC 27001:2022 by the Centre for Assessment. The scope covers Linux consultancy and infrastructure monitoring, management and support, including the use of third-party data centres.

In practice, this means our handling of matters such as access, credentials, changes, staff vetting and security incidents follows a documented information security management system that is independently audited.

We can provide our certificate for supplier checks. Once confidentiality arrangements are in place, we can also share our Security Policy and Statement of Applicability.

Certification does not automatically make your organisation compliant or guarantee that incidents cannot happen. It supports a consistent approach to identifying, managing and reviewing security risks.

No. A short description of what you have and where you need help is enough to start.

If available, useful details include system count, distributions and versions, hosting location, required response hours, known problems and any handover deadline. If you do not know the technical details, explain what the systems do and who relies on them.

Do not send credentials through the enquiry form or by email. When access is needed, we arrange a secure way to share it.

Your first conversation will usually be with Shaun and a member of our support team. We’ll ask about your systems, what is causing difficulty and the help you need. We can explore as much technical detail as you want and discuss likely costs.

The next step depends on your requirements. For ongoing support, we arrange the evaluation and confirm the recommended service and any prerequisite work. A larger or unusual environment may need a separately scoped investigation first.

For a defined project, we agree the work and normally quote a fixed price. If you have an emergency, tell us straight away so we can assess the problem and agree the appropriate help.