Script Support SLA

A script support SLA is an agreement about response times and the scope of work. It is not "build us a new module tonight" and not a free system administrator for your VDS. Confused expectations create angry tickets, so it is better to understand the boundaries from the start.

Check the exact hours and days in your support plan terms. Below is the meaning usually built into such agreements for Microscript PHP products.

What is usually included

• Installation and access incidents: database does not connect, 500 after upload, installer fails, assuming the environment is reasonable.
• Advice on settings from the manual: where to enter SMTP, how to attach cron, where to put files.
• Updates within the supported version line, with the note that the backup is on your side.
• Product bug analysis when it reproduces and is not caused by broken hosting.

How to write a request without making support guess: support and updates.

What is usually not included

• Design work like "make it like a competitor" and new features outside the roadmap.
• Administration of someone else's VDS from scratch: firewall, panel, migration of ten sites.
• Repair after custom hacks were uploaded into the core and then overwritten by an update.
• Ad setup, copywriting, legal texts.
• Teaching PHP from zero.

Some server tasks are covered by manuals: VDS, Nginx, firewall, hosting. That is self-service; SLA does not have to do it turnkey for you.

Response time vs resolution time

Response means "we saw the ticket and answered". Resolution means "it works". Between them there may be waiting for access, logs, or a maintenance window. If the email has no error_log and PHP version, resolution moves into another round of correspondence. That is not sabotage.

Criticality: site down for all users is not the same as "I want the green button further left". Prioritization is exactly what SLA covers.

Updates and backup responsibility

You create a copy before updating: backup. A rollback from your copy is faster than any correspondence. If you updated without a backup and broke custom code, recovery may fall outside the standard SLA.

Migration to a new server is often separate work or a self-service checklist: migration, MySQL migration.

Client environment

Support relies on declared requirements: PHP 8, mysqli, utf8mb4: requirements. If hosting is stuck on PHP 7.2 and the plan cannot be changed, the blocker is not the product. Local testing: MicroServer.

Typical incidents can often be solved before a ticket: database error, 500, permissions, cron.

Monitoring and uptime

A product SLA is not a guarantee of the hosting provider's hardware uptime. A VDS outage at the provider belongs to the provider. Your own monitoring is still useful: monitoring. A hosting hardware contract is separate from script maintenance.

How to speed up ticket work

1. Product name and approximate archive version.
2. URL and reproduction steps.
3. Error text or log fragment.
4. What you already tried from the manual.

Clean installation: installation. SSL and mail often look like script bugs until checked on the server: SSL.

Incident criticality

Typical support levels:

• The site is unavailable to everyone, payment does not open, or data was damaged after an update.
• An important admin section fails, but the storefront is alive.
• Cosmetics, a "how to configure" question, or a new-button request.

The first goes up the queue. The third can wait and often becomes a separate development task outside SLA. Do not mark everything "urgent, client is shouting"; it devalues urgency.

Reproducibility

A bug that happened "once for a client in Safari on iPhone 11" without steps is slow to catch. Record browser, user role, and entity id if present. Local reproduction on MicroServer with your dump greatly speeds analysis. A dump without unnecessary personal data is better; user passwords can be changed after import.

Hosting provider responsibility

A VDS disk failure and three-hour provider repair is not a missed script SLA. Missing mysqli on a shared plan is not either. We can tell you what to enable; you or the host support must enable it. Platform comparison: hosting, VDS.

Communication and maintenance windows

If server access is required, agree on a window. A sudden MySQL restart during peak sales rarely makes anyone happy. Say when work is allowed. After work, expect a short report: what was done and what you should check.

Do not combine an engine update with an ad campaign that goes live tomorrow. Take a backup: backup.

Custom work outside SLA

A new section, a different commission scheme, or integration with a non-standard payment provider is project work and is estimated separately. SLA does not become unlimited development because "you support us". Otherwise the incident queue cannot be planned.

Escalation

If there is no answer beyond the promised response time, reply with the ticket number instead of creating five new emails with different subjects. Duplicates split context. If the question is about support payment, it belongs to billing or sales, not the technical channel with error_log.

The technical minimum is the same: URL, log, PHP, steps. Request manual: support. Your monitoring does not replace SLA but gives facts such as "500 since 03:12 UTC": monitoring.

If the incident is on the hosting side, such as network, disk, or planned maintenance, include the provider ticket number in the script ticket so diagnostics are not duplicated. We cannot speed up a provider node repair, but we can advise how to raise the site on a temporary VDS if it is critical and you have a backup: backup, migration, VDS. Undocumented custom core changes increase analysis time. The further the installation is from the delivered package, the less it is a standard SLA incident and the closer it is to a separate estimate. A clean installation is easier to support: installation, requirements: PHP/MySQL.

In short: SLA is about response and delivered-product maintenance, not unlimited development and not turnkey administration of any VDS. The more precise the ticket and the closer the environment is to requirements, the faster the incident closes. The rest is covered in the support manual.