We use Service Level Indicators (SLIs) to measure quality, Service Level Objectives (SLOs) to define targets, and Service Level Agreements (SLAs) to apply remedies.

Quality guarantees. Protection from errors and omissions. Scoped realistically by project type.

What These Terms Mean Here

SLI
A service level indicator is a measurable signal of service behavior. Examples include availability, response time, error rate, backup freshness, restore validation, notification delivery, and successful completion of critical workflows.

SLO
A service level objective is the target we defend for a given indicator over a defined period. It expresses what “healthy enough” means in practical, operational terms.

SLA
A service level agreement is the client-facing commitment that may incorporate one or more objectives and define what happens if a covered target is missed due to our own failures.

Error Budget
An error budget is the allowable room between perfect performance and the objective we are defending. It helps keep teams honest about tradeoffs between reliability work and expansion work.

In plain English: the SLI is the measurement, the SLO is the target, and the SLA is the promise.

What We Actually Measure

We prefer a short list of meaningful indicators over a giant junk drawer of vanity metrics.

Depending on project type, scope, and operational model, we may measure:

Service availability
Response time and latency
Error rate and failed transactions
Backup freshness and restore readiness
Deployment success and rollback events
Delivery of critical emails, notifications, or automations
Reliability of third-party-dependent workflows
Stability of high-value pages, endpoints, and business functions

We choose indicators that correspond to real business pain. That is the point. Reliability metrics should tell us whether users are being served properly and whether the system remains fit for duty, not merely whether a dashboard looks busy.

What Objectives We Defend

Our SLOs are the operational targets attached to the indicators above. They are selected according to project mission, business criticality, traffic patterns, dependency risk, and the care model under which the project is supported.

In many cases, our internal objectives are stricter than the client-facing commitments attached to the same project. That is deliberate. The goal is not to wait for a public miss and then act surprised. The goal is to detect, tune, and intervene before a client-facing breach occurs.

We also use these objectives to guide escalation, maintenance timing, capacity planning, regression testing, backup strategy, vendor review, and release decisions. Reliability, handled properly, is not a single number. It is an operating discipline.

What Is Contractually Guaranteed

Where a project includes a formal SLA, the applicable agreement defines:

Which services are covered
How performance is measured
Which time window applies
Which maintenance windows or exclusions apply
What remedy is available if a covered target is missed because of our own errors or omissions

Not every project requires the same SLA structure. Some justify service credits. Others are better served by stronger reporting, faster escalation paths, tighter recovery commitments, enhanced monitoring, or stricter operational governance. We prefer to scope those protections deliberately instead of pretending that one public number solves every reliability question.

Where a contractual remedy does apply, approved credits are generally applied to future invoices rather than paid in cash. If a covered event is not automatically credited, or if your organization prefers additional formality for audit purposes, claims may be submitted within the period defined by the applicable agreement.

Exact thresholds, formulas, caps, and covered services belong in the agreement, statement of work, or care schedule for the project in question. This page provides the governing logic, not a one-size-fits-all fiction.

Maintenance Windows, Exclusions, and Shared Responsibilities

Reliability commitments need boundaries to mean anything.

Planned maintenance windows, emergency maintenance, force majeure events, upstream provider outages, client-side access problems, unsupported or unapproved customizations, policy breaches, and other out-of-scope conditions may affect whether an event counts against a contracted target. So may traffic or usage conditions that exceed agreed capacity after we have already advised that upgrades or mitigations are needed.

This is not about dodging responsibility. It is about measuring responsibility accurately.

We prefer to make shared responsibility explicit early: what we own, what you own, what depends on third parties, and what depends on agreed operating conditions. That clarity protects working relationships, reduces surprises, and helps everyone make better decisions under stress.

Incident Response, Reporting, and Governance

Reliability is not only about credits after breakage. It is also about how breakage is detected, contained, explained, and reduced over time.

Our reliability model is supported by operational disciplines such as:

Logging and monitoring
Backup and recovery routines
Compatibility and viability testing
Regression testing
Release controls and rollback discipline
Escalation paths and incident response processes
Post-incident review and operational refinement
Recurring reporting appropriate to the project and care model

This matters because serious reliability work lives in process, not just in promises. Monitoring without response discipline is theater. Promises without reporting are fog. We prefer neither.

Reliability Profiles by Project Type

Different projects deserve different reliability treatment.

Public Websites and Publishing Systems

These projects often prioritize availability, content delivery, backup integrity, performance stability, search-safe operations, and publishing continuity.

Member Areas, Portals, and Transactional Systems

These projects usually require tighter attention to authentication, data integrity, notification delivery, recovery readiness, and incident response posture.

AI Assistants and Agentic Workflows

These systems may require reliability definitions that go beyond uptime alone. Model behavior, vendor dependency, logging, guardrails, prompt stability, and workflow completion reliability can matter just as much as raw availability.

Internal Operations and Multi-Team Environments

These often require stronger governance around access control, change management, backup and recovery, service accounts, secrets, vendor coordination, and runbook quality.

We do not force every project into the same box. We define the right reliability profile for the actual mission.

Portability and Service-Level Boundaries

We design for portability where it is commercially and operationally sensible.

If a capability is integrated into your implementation, it remains with the project. That includes base and addon implementation work that becomes part of the delivered system itself.

By contrast, many care-level behaviors depend on our own managed environments, monitoring layers, automation, staffing models, runbooks, reporting routines, or other internal and proprietary operating processes. Those do not automatically travel intact when a project leaves our ecosystem.

That distinction is important. It protects clarity. It also prevents the common trap in which a provider quietly bundles operational magic into the project itself and then pretends it is all equally portable. It is not. We would rather say so plainly.

Where exit support, transition support, or reduced-portability alternatives are feasible, they can be scoped separately.

Quick Questions

Does every project include a formal SLA?

No. Some projects benefit from a formal SLA. Others are better served by strong care processes, recurring reporting, and clearly defined recovery and escalation practices without a credit-based agreement.

Are SLOs always public?

No. Many SLOs are internal operational targets rather than client-facing promises.

Do the same service levels apply outside your managed ecosystem?

Not always. Some support is available outside our environments, but complete care and maintenance capabilities are only available where we have the administrative and operational control required to deliver them properly.

Are credits the main point of this page?

No. Credits matter when they apply, but the larger goal is disciplined reliability: measured service behavior, defended objectives, clear responsibilities, and mature incident handling.

Can you help define SLIs and SLOs for a project that does not have them yet?

Yes. In many cases, that is the more valuable starting point.

Next Step

Already have reliability requirements from procurement, compliance, IT, leadership, or risk management? Bring them.

Do not have them yet? That is normal too.

We can help define a reliability profile that fits your project’s actual mission, risk tolerance, dependency map, and care model. We can also help distinguish what should be measured, what should be defended internally, what should be promised contractually, and what should remain outside the agreement.

That usually leads to stronger delivery, better provider-client relations, and fewer unpleasant surprises once the project is live.

...

EhvenConsultants provides services and solutions that integrate and build upon the very best technologies available in our chosen service ecosystems.

We are pleased and proud to stand behind our offerings with aggressive SLAs that protect our clients' interests and allow us to continually demonstrate our faith in the quality of our work.

Service Availability and Uptime

Updated March 2, 2021.

This SLA document details all standards, terms, and remedies of currently supported Service Level Agreements. The remedies set forth in this SLA are Client’s sole and exclusive remedy for issues covered by the SLA.

We reserve the right to make changes to this SLA at any time and at our sole discretion. If and when we make changes to this SLA, notice of such changes is provided via revised update date at the top of this SLA. Continued use of our Services and Solutions following notification of changes constitutes acceptance of such changes. Please review this SLA periodically and check for any updates.

Definitions

Adjusted Monthly Service Plan Value
If Client switches Service plans during the Monthly Billing Period (defined below), the Adjusted Monthly Service Plan Value is calculated based upon the amount of time spent on each plan during the Monthly Billing Period (see examples below).
Covered Downtime
Total duration in minutes of Downtime (defined below) occuring during a Monthly Billing Period (defined below).
Downtime
Time in which Necessary Access Services (defined below) are unavailable to Client.
Effective Service Plan
Active DevOps plan at the time Downtime (defined above) occurs.
Hosting and Operations Portions
DevOps and Website/App Care Plans include hosting, operations duties (tested updates, server refreshes, etc), license fees, and, potentially, internal tooling use fees. The Hosting and Operations Portions of these plans are:
- Google Cloud Platform Live server pairs: $128 per month (covers one Production container and one Staging container)
- Google Cloud Platform RemDev server pairs: $108 per month (covers one Production container and one Staging container)
- MultiDC GCP server pair clusters: $128 per month per pair in every load-balanced or failover cluster (covers one Production container and one Staging container)
Maintenance Period
Monday through Sunday, 2 am to 5 am, local time, based upon the time zone of the data center in which each Client project is hosted.
Monthly Billing Period
The period starting at the beginning of the first day of the calendar month and ending and the conclusion of the last day of that same calendar month. If there is a difference between these times as relates to our local time (ET USA), Client local time, or data center local time, the most permissive time is used (this is usually the latest of the three times).
Monthly Renewal Date
The first calendar day of the month regardless of the date on which agreements were signed or projects were released to web.
Monthly Service Plan Value
For Clients on a monthly billing cycle, the Fee paid every month for the Hosting and Operations Portions (defined above) of the Effective Service Plan (defined above). For clients on an annual billing cycle, the Fee paid every year for the Effective Service Plan (defined above), divided by 12. The Monthly Service Plan Value excludes any other fee or amount, such as but not limited to, bandwidth or capacity overages, added or augmented feature change requests, supplemental and R&D projects, and third-party subscriptions.
Necessary Access Services
Aspects and features of the Services that must be operational in order for a Client project hosted on our platform to be accessible over Hypertext Transfer Protocol (HTTP). Necessary Access Services do not include third-party services, our website, SSH/SFTP access, or any other portion of the Service that is not strictly necessary in order for Client projects to remain accessible.
Qualified Client Account
The account of Client, as maintained in our system for communications, service tracking, and all other contracted deliverables and relationship features, as long as Client is neither absent nor delinquent, and Project is not Abandoned, Suspended, or Deleted.
Release Date
The date on which Client project is deemed by all participating parties to be ready for release to web.
SLA Credit
The credit, as described in this SLA, that is applied to Client account and redeemable on subsequent invoices.
Uptime Guarantee
The Necessary Access Services (defined above) will be available at least 99.9% of the time during each Monthly Billing Period (defined above).

SLA Credits

To determine whether our Uptime Guarantee has been met, Covered Downtime is compared to the amount of time in a normal 30-day period (43,200 minutes). If Covered Downtime exceeds 30 minutes (0.0694% of the amount of time in a normal 30-day period), this Uptime Guarantee may be regarded as unmet (pending determination of downtime cause).

If we fail to meet the Uptime Guarantee, Client will receive SLA Credits equal to five percent (5%) of the Monthly Service Plan Value for each half hour (30 minutes) of Covered Downtime. Covered Downtime is calculated based on a combination of monitoring tools integrated into our platform, and data center monitoring (provided by Google Cloud Platform systems and personnel).

SLA Credit Examples

Downtime credit assignment examples:

If Covered Downtime is 29 minutes, no SLA Credit is issued.
If Covered Downtime is 30 minutes, Client is issued SLA Credit equal to 5% of Client’s Monthly Service Plan Value.
If Covered Downtime is 59 minutes, Client is issued SLA Credit equal to 5% of Client’s Monthly Service Plan Value.
If Covered Downtime is 1 full hour (60 minutes), Client is issued SLA Credit equal to 10% of Client’s Monthly Service Plan Value.

Adjusted Monthly Service Plan Value example:

In a Monthly Billing Period consisting of 30 days, if Client spent 10 days on a plan costing $128 per month and 20 days on a plan costing $256 per month, the Monthly Plan Value would be $210.67 ( $120 divided by 30 and then multiplied by 10, plus $256 divided by 30 and then multiplied by 20) and SLA Credits are issued based upon the Adjusted Monthly Service Plan Value of $211.

SLA Credit Redemption

SLA Credits are granted automatically. To support audit trail requirements of organizations that prefer an additional level of formality as relates to SLA management, and, to account for the rare case in which we are not aware of a covered outage, we also provide SLA Claim forms. If Client wishes to make an SLA Claim for an apparent outage that was not automatically detected and credited by us, the claim must be filed within 30 days of the alleged outage event. An SLA Claim form may also be submitted after credit has been applied (useful to some organizations that prefer greater formality in SLA management, as mentioned above).

SLA Credits are added to Qualified Client Account and applied to future invoices. SLA Credits will not exceed the Monthly Plan Service Value for the month in which we failed to meet our availability guarantee and will not be paid in cash. If Client abandons Project and/or terminates Account or Agreement before SLA Credit is applied, no credit is issued.

SLA Credit Exceptions and Exclusions

Downtime caused by any of the following circumstances, as determined at our sole discretion, is not included in Covered Downtime and is not eligible for SLA Credit:

Outage incurred during planned Maintenance Period
Emergency maintenance performed at any time
Force majeure events, including but not limited to, acts of nature (fire, flood, earthquake, storm, or other natural disasters), acts of war (invasion, hostilities, rebellion, revolution, insurrection, terrorist activities, and other hostile activities), actions taken by governments (sanction, blockage, embargo, and other governmental action), labor disputes (strike, lockout, or any similar dispute), outages caused by external service providers, and any other event which we cannot reasonably anticipate, prevent, control, or avoid
Traffic reaching a Client Website that exceeds the capabilities of the Client Website if due to Client-made changes or customizations, or the Client’s Service plan if previously advised in writing that capacity upgrades are recommended for proper management of emerging conditions
Client breach of existing agreements or policies
Client machine access problems
Client authored code (unless mitigated by appropriate WebOps-class DevOps plan agreements)