Last updated: 7 September 2026

Service Level Agreement Summary

The short version: if you are on an active support retainer with us, this page tells you when we are available, how fast we aim to respond to each severity of problem, how to raise a ticket that we can act on quickly, and what falls outside the agreement. It is a summary. Your signed contract is the document that counts.

• 1. Who this applies to
• 2. Support hours
• 3. Severity levels and targets
• 4. How to raise a ticket
• 5. Escalation path
• 6. Exclusions
• 7. How uptime is measured
• 8. Reporting and review
• 9. The signed contract prevails

1. Who this applies to

This summary applies to clients on an active maintenance and support retainer with Truestep Solutions, for the systems named in that retainer. It applies only while the retainer is in force and invoices are up to date.

It does not apply to project work under a fixed scope or dedicated team engagement, which is governed by the milestones and acceptance criteria in its own statement of work. It does not apply to anyone using our free our own apps, including Apex Health: Sleep & Recovery, where support is offered on a best effort basis through the Apex Health support page with no committed response time.

2. Support hours

Standard support hours are 09:30 to 18:30 India Standard Time, Monday to Friday, excluding public holidays observed by the company. We publish our holiday list to retainer clients at the start of each year.

Response targets are measured in support hours, not in wall clock hours. A ticket raised at 18:00 on a Friday has its clock paused at 18:30 and resumed at 09:30 on the next working day, so the remaining time carries over rather than being lost. Tickets can be raised at any time, and outside support hours they are queued and picked up when the next working day begins.

Critical incidents are the exception. Where the retainer includes out of hours cover, a Critical ticket raised through the emergency channel named in the retainer is answered around the clock, on the target below, including at weekends and on holidays. Where the retainer does not include out of hours cover, a Critical ticket raised outside support hours starts its clock when the next working day begins, and we will say so plainly when you sign rather than leave it as a surprise.

3. Severity levels and targets

We assign a severity when a ticket is accepted, based on the business impact you describe rather than on how the fault looks technically. If you disagree with the severity we assign, say so and we will discuss it and change it where you are right. Target first response means a human being who has read your ticket replies with an assessment and the next step, not an automatic acknowledgement.

These are targets we work to and report against, not guarantees for every individual ticket. Some faults sit in a third party service or need a vendor to act, and in those cases we will keep you informed of what we are doing and what we are waiting for. Where a severity is raised or lowered after investigation, the target for the new severity applies from the moment of the change.

4. How to raise a ticket

Raise every ticket by writing to support@truestepsolutions.in, or through the ticketing system named in your retainer if you have one. Please do not report faults through personal messages to individual engineers, because those are not tracked and no clock starts.

A ticket we can act on immediately includes:

• The system or application affected, and the environment, such as production or staging.
• What you expected to happen and what actually happened.
• The exact steps to reproduce the problem, and whether it happens every time.
• When it started, and whether anything changed just before that.
• How many users are affected and what they cannot do, which is what drives the severity.
• Error messages, screenshots, request identifiers, log extracts or timestamps in India Standard Time.
• A named contact who can answer questions and confirm when the fix works.

The response clock starts when the ticket arrives at the support address with enough information to assess it. If we have to come back for basic details, the clock pauses until you reply. One ticket per problem, please, because merged threads are hard to track and easy to lose.

5. Escalation path

If a ticket is not moving, or if the impact grows, escalate rather than waiting. Reply on the existing ticket with the word "Escalate" and the reason, so that the history stays in one place.

• First step. The assigned engineer, on the ticket itself. Most delays are cleared here.
• Second step. The engagement lead for your account, who can reprioritise work, pull in another engineer or change the plan. We aim to bring the engagement lead in within one support hour of an escalation on a Critical or High ticket.
• Third step. The director responsible for delivery, for anything unresolved after the second step, for a repeated failure to meet a target, or for a dispute about severity or scope. Write to hello@truestepsolutions.in to reach this level directly.

For a Critical incident we will also open a direct channel, such as a call or a shared chat, alongside the ticket, and give you updates at an agreed interval until service is restored. After every Critical incident we write a short review covering what happened, what we did, why it happened and what we are changing, and we share it with you.

6. Exclusions

The targets above do not apply, and the clock does not run, in the following situations.

• Third party outages. A failure in a cloud provider, hosting platform, payment gateway, email service, DNS provider, app store, external API or any other service we do not operate. We will diagnose it, raise it with the vendor, keep you informed and help you work around it, but we cannot commit to a resolution time for somebody else's platform.
• Client caused changes. Faults caused by changes made by you or by another supplier, including deployments, configuration changes, database edits, credential or certificate changes, infrastructure changes and content changes made outside the agreed process. We will still help, charged as agreed, but the targets do not apply.
• Work outside the agreed scope. New features, new integrations, redesigns, migrations, data cleanup, performance work beyond the agreed baseline and systems not named in the retainer. These are quoted as a change request or a separate statement of work rather than handled as tickets.
• Unsupported versions and environments. Software, frameworks, operating systems or browsers that are past end of life, or environments that differ from the agreed supported set, where we have already recommended an upgrade in writing.
• Access not granted. Any period in which we do not have the access, credentials, environments, data or approvals needed to investigate or deploy a fix.
• Force majeure. Events beyond reasonable control, including natural disasters, extended power or network failure in a region, government action and cyber attacks not caused by our negligence.
• Suspended accounts. Any period in which the retainer has lapsed, has been suspended, or has invoices unpaid past the due date after a written reminder.

7. How uptime is measured

Where the retainer covers a system we host or operate, uptime is measured monthly, over each calendar month, as the number of minutes the monitored endpoints responded successfully divided by the total number of minutes in the month, expressed as a percentage. The commitment for a given system is written in the retainer.

Measurement uses an external monitoring service that we name in the retainer, checking the agreed health endpoints at a fixed interval from more than one location. A minute counts as down only when checks fail from more than one location, so that a fault in one monitoring region does not count against the system. The monitor's record is the source of truth for measurement, and you get access to it, so neither side has to take the other's word for what happened.

The following minutes are excluded from the calculation:

• Planned maintenance announced in advance, with at least the notice period stated in the retainer, and in the absence of a stated period, at least 48 hours of notice, scheduled in an agreed low traffic window.
• Emergency maintenance needed to close a security vulnerability, which we announce as early as we reasonably can and keep as short as possible.
• Downtime caused by anything listed in the exclusions above, including third party outages, client caused changes and force majeure.
• Downtime caused by traffic far beyond the agreed capacity of the system, where we had recommended additional capacity in writing.
• Suspensions we are required to make by law, by a regulator or by an upstream provider's acceptable use rules.

If a system misses its committed uptime for a month, the remedy is the service credit set out in the retainer, applied to the following invoice. Service credits are the agreed remedy for missed uptime.

8. Reporting and review

Each month we send retainer clients a short report covering tickets raised and closed by severity, how our responses measured against the targets, uptime for hosted systems, work carried out against the retained capacity, and anything we recommend for the coming month. We also hold a review at an agreed interval to look at recurring problems and to decide what is worth fixing at the root rather than repeatedly patching.

9. The signed contract prevails

This page is a plain English summary, published so that anyone can see how we work before they sign anything. It is not the agreement itself. Where your signed retainer, master services agreement or statement of work differs from this page on hours, severities, targets, exclusions, uptime, service credits or anything else, the signed document prevails for your engagement. Where the signed documents are silent, this summary describes our default practice. We may update this page as our practice changes, and the date at the top always shows the current version.