99.99% annual target • HU + EU infrastructure • Credit-based compensation
SecureLayer – Service Level Agreement
This page is the public SLA summary for SecureLayer. Its purpose
is to clearly explain the availability targets, operational
principles and service credit rules behind the service.
1. SLA Summary
SecureLayer aims to operate critical DNS and EDGE services
with high availability, using multiple locations and
separated infrastructure layers.
| Metric |
Commitment / Target |
| Availability |
99.99% annual target |
| Maximum theoretical annual downtime |
approx. 52 minutes |
| Infrastructure |
Hungarian + EU-oriented geo-redundant architecture |
| Compensation |
25–100% as service credit |
Important: this document is a customer-friendly
summary of the technical and operational commitments of the
service. It is not a full internal architecture description.
2. Purpose of this document
The SecureLayer Service Level Agreement defines the
availability targets related to DNS and EDGE services, the
main operational principles, exclusions and possible service
credit rules.
What does it apply to?
- availability of the public DNS service
- availability of EDGE proxy and related core platform functions
- core infrastructure components managed by SecureLayer
What does it provide?
- transparent availability targets
- clear incident handling and compensation framework
- customer-friendly SLA interpretation
What does it not provide?
- non-public internal protection logic
- a complete technical blueprint
- a replacement for an individual enterprise agreement
3. Infrastructure and geo-redundancy
SecureLayer is designed so that critical DNS and EDGE
functions do not depend on a single point. The platform is
based on multiple roles, separated layers and redundant
operation.
Hungarian presence
- multiple domestic data center presence
- redundant nodes and separated roles
- geographical separation for service stability
EU expansion
- integration of foreign EU locations
- geo-redundant DNS and EDGE presence
- improved resilience in case of local outages
Network separation
- role-based server separation
- separated DNS, EDGE, panel and management layers
- ACL, firewall and internal network rule enforcement
4. Guaranteed availability
SecureLayer sets an annual 99.99%
availability target for the DNS + EDGE infrastructure and
core platform functions.
| Period |
Maximum theoretical downtime |
| 1 year |
approx. 52 minutes |
| 1 month |
approx. 4.3 minutes |
| 1 week |
approx. 1 minute |
What supports this commitment?
- parallel operation of multiple DNS nodes
- multiple EDGE endpoints and traffic distribution
- monitoring and rapid operator intervention
What is not directly covered?
- the customer’s origin server
- errors in the customer’s own application
- outages of external third-party systems
5. Incident handling and response times
Critical incidents are processed based on automated alerts,
while less severe issues are handled according to operator
priority.
| Priority |
Description |
Expected response time |
| P1 – Critical incident |
The service is unavailable. |
1–30 minutes |
| P2 – High priority incident |
The service is running, but with significant degradation or malfunction. |
1–2 hours |
| P3 – General request / issue |
Non-critical operational or administrative request. |
24 hours |
Response time means the start of the first operator review
or automated intervention. It does not always mean final
resolution of the incident.
6. Failover and monitoring
Redundancy is valuable when the system can detect failures
and route traffic or service functions to working components.
Detection
- monitoring of DNS, EDGE and panel components
- status checks from multiple points
- detection of errors, slowdowns and SSL-related issues
Isolation
- isolation of faulty components or routes
- protection of the remaining service layers
- operator and automated intervention options
Rerouting / recovery
- routing traffic to another node or working path
- service restoration
- final repair and post-incident verification
7. Maintenance windows
The goal is to minimize service impact, but certain
operations may require a short maintenance window.
Planned maintenance
- performed preferably within a previously communicated time window
- typically no more than 1 hour per month
- pre-announced maintenance does not count as SLA downtime
Emergency maintenance
- may be performed for urgent security or operational reasons
- notification is provided as soon as reasonably possible
- typically required in case of incidents or vulnerabilities
Goal
- controlled execution of updates
- maintaining stability and security
- reducing downtime risk
8. SLA exclusions
Not every issue qualifies as an SLA event. The service level
does not cover every incident caused on the customer side or
by third parties.
Customer-side issues
- incorrect origin configuration
- wrong DNS record or firewall configuration
- application or web server errors
Third-party failures
- failure of external email or API providers
- external DNS, CDN or upstream issues
- outages not controlled by SecureLayer
Force majeure / extraordinary circumstances
- national or regional network disruption
- natural disaster
- regulatory, authority or upstream-level intervention
9. Compensation policy
If the committed availability level is proven not to be met,
compensation may be provided as service credit for upcoming
billing cycles.
| Annual availability |
Service credit |
| 99.0% – 99.99% |
25% of one monthly fee |
| 98.0% – 99.0% |
50% of one monthly fee |
| Below 98% |
100% of one monthly fee |
Important conditions
- service credit is provided as account credit
- it is not automatically paid out in cash
- it applies to the affected plan and service period
- SecureLayer internal monitoring data is authoritative during review
- individual enterprise agreements may define different terms
10. SLA contact
If you would like to clarify what the SLA applies to, or if
you have individual business / enterprise requirements,
please contact us.
Email:
admin@securelayer.hu
Client panel:
panel.securelayer.hu