Skip to main content

How do I work out a good String Check / Action Plan for my SLA?

As part of our Service Level Agreement(SLA), we need two things from you for its implementation: a string check and an action plan. In the following article we would like to explain to you in more detail what these are and what you should pay attention to when creating them.

What is the purpose of a string check?​

The purpose of a string check is to verify that a web page behaves as expected and can be delivered properly.

Since elements are often generated across multiple application and infrastructure components (e.g. web server, PHP execution, database connection, key-value stores), such a test ensures that your application works correctly and the interaction between services is successful.

What can a string check look like?​

A simple example of such a test is checking for the output of the sales tax number from the imprint. The imprint is usually generated dynamically by your application and draws data from several infrastructure components. Moreover, the sales tax number is not subject to fluctuations and is therefore a reliable indicator.

Based on this example, core criteria of a check can already be seen:

  • The return should be reproducible and consistent
  • The check should include as many components of the application and infrastructure as possible

The string check can also be generated by you in a more complex procedure. It is conceivable that you test individual components of your application in the background and then issue a success message. This success message is checked by us. In case of a deviation, we trigger an alert, which is sent once to your technical contacts, as well as transmitted to our alerting.

The following checks can be performed, for example:

  • Can a database connection be established?
  • Is write access to the database possible?
  • Is the creation and access of sessions possible?

What must not be checked by the string check?​

  • Dependencies on systems that are not hosted by Nine
  • Dependencies on ROOT or cloud servers
  • System metrics such as storage space or CPU utilization. These are monitored by Nine, independently of the SLA.

Adjustments to your application​

It must be possible to check the string check at any time. This includes times when you release a new version of your application.

If this cannot be guaranteed, you are obliged to notify Nine Internet Solutions AG in advance of the time of the planned downtime. The monitoring of the string check will then be suspended for this period.

You can notify us via https://cockpit.nine.ch under the menu item "Account" - "Events" or via email to .

Action plan​

Why is an action plan needed?​

An action plan defines steps to be taken in case of deviations from the expected return value of the string check.

Without an action plan, we have limited ability to help you keep your application available. When considering the string check or action plan, you should always assume that your application is completely unknown to us. It is therefore essential for us that you document the measures to be taken in the application environment as precisely as possible for us.

What do you have to consider when working out a plan of measures?​

  • Assume that we do not know your application. Explain step by step which action we should take under which circumstances.
  • We execute the action plan "blindly". If a step should only be executed under certain conditions (because it is destructive, for example), these conditions should be clearly formulated.
  • It is only about your application. Assume that the system environment is working correctly.
  • For each step, describe the following:
  • What is it supposed to do?
  • How will it be executed (exact "step by step" instructions)?
  • What is the expected result/output?
  • An action plan may include "if, then, else" conditions.
  • Document the location where your application creates log files. This information helps in analyzing a problem at hand.

What does not belong in the action plan?​

  • Restart of services / servers that are managed by Nine (e.g. Apache / MySQL). These are monitored by us independently of the SLA, a restart of services in case of failures is entirely at our discretion.
  • Restart of services in "User Space". If you want to run applications in "user space", you can find more information about this in our article Manage daemons as users with systemd.
  • Trivial instructions. If your string check can detect error "X" and the solution to this is to flush the cache, you should automate this action.
  • Escalation. At the moment when we receive the information about an error, you have also already been informed automatically via the stored contact option (SMS or email). We will inform again when the problem is solved or when the actions defined in the action plan cannot solve the problem. From this point on, until the customer actively asks for support, the issue is considered closed for us.

Acceptance / Adjustments​

The string check and action plan must be accepted and confirmed by us. We must be notified of any changes to the application that affect the string check or action plan, and the changes to the string check and/or action plan must also be accepted by us.

New responsibilities, changed telephone or email contacts or adjustments to existing contacts must be communicated to us immediately so that we can inform you of problems at any time.