Service Level Indicators: what we measure and how
This page describes the Service Level Indicators (SLIs) we use for client projects, how we measure them, and where the boundaries of those measurements lie. We publish this information so you can understand not just the target values, but also the methodology, limitations, and how to interpret the metrics.
Uptime ≥ 99.5% (target 99.8%)
P95 latency · API < 300 ms
Error rate < 0.1%
UptimeRobot · Grafana · Prometheus
Lighthouse CI in the pipeline
RED + USE methodology
uptime · last 30 days · target ≥ 99.8%
Key facts
An SLI is what gets measured. An SLO is the target we work towards. An SLA is the commitment written into the contract. This page shows the actual metrics and tools we use; project-specific thresholds are set in the SOW after an audit.
baseline uptime SLO (target 99.8%)
P95 latency on API endpoints
error rate (HTTP 5xx)
first response to S1 incidents during business hours
RED + USE
RED for requests (Rate, Errors, Duration), USE for resources (Utilization, Saturation, Errors).
UptimeRobot · Grafana · Prometheus · Nightwatch · Lighthouse CI
New Relic APM is available as an alternative. We choose the stack to fit your project's architecture.
P50 · P95 · P99
Averages hide the worst case. Percentiles show what your slowest users actually experience.
LCP ≤ 2.5 s · INP ≤ 200 ms · CLS ≤ 0.1
Lighthouse CI in the pipeline blocks a deployment if performance regresses critically.
24/7, not just business hours
Metrics are collected around the clock. On-call response depends on your plan.
SOW · SLA
Specific SLOs and commitments are set out in the contract. This page is for information only.
How to read this page
This page is informational in nature. The SLI and SLO values listed here are typical benchmarks for managed projects and do not replace the specific terms outlined in your contract, SOW, or SLA.
SLIs are measurable metrics — not marketing promises. Every figure is backed by a specific data collection tool.
SLOs on this page are benchmarks for common scenarios. Final target values are set after onboarding and an architecture review.
Data sources depend on the project setup: external synthetic checks, infrastructure metrics, APM, and CI audits.
May be excluded from calculations: scheduled maintenance windows, force majeure events, and third-party outages, per the terms of the agreement.
Actual reporting and dashboard access depend on your chosen support plan.
Why SLIs matter for your business
When a client hands off a project for ongoing support, the expectation is usually straightforward: the website or application should run smoothly, quickly, and predictably. But “everything's running fine” is too vague for proper quality management. SLIs translate that into measurable metrics you can verify, compare, and discuss based on real data.
What's happening right now?
Real-time monitoring catches any deviation immediately.
How stable has the service been over time?
Historical data reveals trends and seasonal patterns.
When do we need to step in?
Threshold values trigger alerts before a user ever notices a problem.
The practical value of SLIs for your business: less guesswork, earlier detection of performance degradation, and the ability to make decisions about your project's development based on facts rather than gut feelings.
SLI, SLO and SLA: how they fit together
The three layers of service quality build on each other: measurement → targets → commitments.
Trust & Legal
GDPR compliance
Data protection compliance
We process personal data in line with the principles of the General Data Protection Regulation (GDPR): we minimize the data we collect, define purposes and retention periods, respect data subjects' rights, and apply these requirements to logs, analytics and backups.
Trust & Legal
ISO 27001 and SOC 2
working towards certification
We build our information security on ISO 27001 and SOC 2 principles: least-privilege access management, documented policies, a Secure SDLC, DevSecOps practices and internal audits.
Trust & Legal
NDA and confidentiality
Protecting your business information
Every Webdelo project is covered by an NDA by default. We restrict access to data and repositories by role and use secure channels and secret managers. We never pass client materials to external services or public AI models without separate consent.
The core principle: SLIs feed SLOs, and SLOs shape SLAs. Without reliable indicators, any guarantee is just words. That's why we start with measurement.
What we measure
We track metrics that affect user experience, service stability, and the manageability of support. The exact set of metrics may vary by project, but the core indicators and how we calculate them stay consistent.
Core indicators
Core Web Vitals
Google uses Core Web Vitals as a ranking factor. We track them separately because they directly impact SEO and conversion rates.
Lighthouse CI runs automatically in the deployment pipeline. If Core Web Vitals degrade after an update, we know about it before it affects your search rankings.
Additional indicators
The values in the tables above serve as baseline benchmarks. For a specific project, they're refined after onboarding based on architecture analysis, load profile, and business criticality.
How we measure: tools and methodology
The reliability of metrics depends not just on the tool, but on how it's used: check frequency, alert configuration, monitoring locations, data retention, and correct interpretation. That's why we use a combination of external synthetic monitoring and analysis at the infrastructure and application levels.
Grafana overview dashboard with key project metrics.
UptimeRobot
Synthetic checks from multiple geographic locations every 1–5 minutes
HTTP/HTTPS, Ping, port checks, DNS, SSL monitoring
Instant notifications on downtime via email, Slack, Telegram
Historical uptime data for reporting
Public status pages for transparency with end users
Grafana + Prometheus
Prometheus collects metrics from servers and applications, Grafana visualizes them on customizable dashboards
Latency (P50, P95, P99), error rate, throughput — in real time
Server resource monitoring: CPU, RAM, disk, network
Configurable alerts when thresholds are exceeded
Historical trends to catch degradation before it becomes an incident
Grafana — project availability and health status history.
Latency and error rate dashboard.
Aggregated application logs.
Laravel Nightwatch
Deep instrumentation for Laravel applications, built by the framework's creators
Tracing every request from entry to response
Detection of slow SQL queries and queue bottlenecks
Real-time exception and error monitoring
Tracking background jobs and cron schedules
Alternative: on some projects we use New Relic APM, a full-featured performance monitoring platform. The choice depends on the project's architecture and client requirements.
Request tracing.
Request list.
at App\Http\Controllers\OrderController->show:34
at App\Http\Middleware\Authenticate->handle:18
GET /api/orders/8341 · trace_id=a3f8b91c
Exception with stack trace.
Lighthouse CI
Automated performance audits with every deployment
Runs in the Bitbucket Pipelines CI/CD pipeline
Compares metrics against the previous release — regressions are caught immediately
LCP, INP, CLS, plus accessibility and SEO audits
Blocks deployment on critical performance drops
Bitbucket Pipelines · last run 8 min ago · deploy blocked below 90
Methodology
For web applications, we use the RED approach (Rate, Errors, Duration) — the three key signals that are first to react when user experience degrades. For infrastructure metrics, we use the complementary USE approach (Utilization, Saturation, Errors).
From the user's perspective
Not internal server metrics, but the real experience: page load times, action success rates, wait times.
Percentiles, not averages
P95 and P99 show the worst experience real users are having, not the “average across the board.”
Continuous, 24/7
Metrics are collected around the clock, not just during business hours.
Thresholds are reviewed quarterly, after every significant incident, and whenever the load profile changes.
Error Budget — your budget for acceptable errors
No service runs without hiccups. The Error Budget is an engineering approach that turns this reality into a manageable number: the acceptable amount of downtime or errors within a period that keeps the service within its SLO.
Full speed ahead
You can ship updates, deploy new features, and experiment.
Focus on stability
Critical fixes only, more rigorous testing.
Change freeze
Changes are frozen until the buffer is restored. Priority goes to fixing root causes.
Why this matters to you: The Error Budget helps us make decisions based on data, not emotions (“let's not touch anything”). This means your project moves forward as fast as possible at your chosen level of reliability.
Monitoring levels by support plan
The depth of monitoring and the range of tracked SLIs depend on your chosen support plan.
* Enterprise plan targets are set on a case-by-case basis after onboarding and an architecture review.
Incident severity model
All incidents are classified by their business impact. Each severity level has its own response targets.
Transparency and reporting
SLIs are only valuable when they're accessible and easy for you to understand. We don't hide metrics — we make them the foundation for decisions we make together.
What's included in an SLI report
Reporting frequency
Our approach to reliability
SLIs aren't just numbers in a report. They're the foundation of an engineering culture that shapes our day-to-day decisions.
Restore-first
When an incident hits, the priority is restoring service — not finding the root cause. The investigation starts after the service is back up and running.
No surprises
If something goes wrong, you hear about it from us — not from your own monitoring. Proactive notifications are part of how we operate.
Blameless postmortem
After every significant incident, we run a review without finger-pointing. The goal is systemic improvement, not blame. The outcome: specific actions to prevent a repeat.
Automated monitoring
Everything that can be automated, is automated. Our engineers make decisions — they don't manually check dashboards.
Clear ownership
We're responsible for code, deployment processes, and monitoring. Hosting infrastructure, access credentials, and third-party contracts fall under the client's responsibility. This clear division makes it possible to set realistic SLO targets.
Quarterly review
Thresholds and SLOs are reviewed every quarter and after major incidents.
Scope of responsibility and exclusions
A clear division of responsibilities makes SLIs meaningful and interpretable. Without it, metrics and targets can easily become misleading.
Our responsibility
Application code, deployments, and CI/CD pipelines
Setting up, maintaining, and evolving the monitoring system
Incident response, root cause analysis, and corrective actions
Core Web Vitals monitoring and optimization recommendations
Error Budget management and SLI reporting
Client responsibility
Hosting infrastructure and DNS, unless transferred to our management
Third-party services and APIs: payment systems, CRM, email providers, and other external dependencies
Managing access credentials, user accounts, and internal security policies
Content, settings and user actions in the admin panel
Providing data and access needed for diagnostics in a timely manner
What SLIs typically don't cover
Force majeure
Major provider outages, data center failures, natural disasters.
Scheduled maintenance
Pre-agreed maintenance windows.
Unauthorized changes
Changes made by the client or third parties without our team's involvement.
External dependencies outside our control
Third-party APIs, CDNs, email and payment services.
The specific scope of responsibility and list of exclusions are defined in the contract and may vary depending on the project architecture and chosen support plan.
