Service Level Agreement

Hostelastic Technologies LLP guarantees that the Covered Service will be available to Customer at least 99.9% of the time in any calendar month (the “PIXELQODE SLA”).

If we do not meet it, and Customer meets its obligations below, Customer is eligible for the Service Credits described here. This document states Customer’s sole and exclusive remedy for any failure by Hostelastic Technologies LLP to meet the PIXELQODE SLA.

This SLA applies to the Scale, Business and Enterprise plans. Growth are provided without an uptime commitment.

• “Covered Service” means two separately measured components: the Application — the PIXELQODE web application and its API served from pixelqode.com, covering signing in, creating and editing codes, generating and downloading artwork, and reporting — and the Redirect, the service that resolves scans of dynamic codes on our short-link domain.
• “Downtime” means, for a component, a period in which requests to its monitored endpoints fail on consecutive checks from at least two independent monitoring locations. A check fails if the connection cannot be established, no response is received within thirty (30) seconds, or the response is an HTTP 5xx. A 2xx or 3xx response is a successful check — the Redirect answers a scan with an HTTP 302 by design, and a redirect delivered is the service working.
• “Monthly Uptime Percentage” means, for each component separately, the total number of minutes in a calendar month minus the minutes of Downtime for that component, divided by the total number of minutes in that month.
• “Service Credit” means a credit against Customer’s next invoice, calculated as a percentage of the monthly-equivalent Fee for the affected workspace, per the table below.

Availability is measured by UptimeRobot, an independent third-party monitoring service that is not operated by or affiliated with Hostelastic Technologies LLP and that holds SOC 2 certification. It checks the Application and the Redirect continuously from multiple global locations at intervals of no more than five (5) minutes.

UptimeRobot’s records are the sole source of truth for Monthly Uptime Percentage under this SLA. Measurements taken by Customer or by any other tool — including a browser that could not load a page, a scan that did not work on one phone, or a monitor checking an endpoint we do not monitor — do not establish Downtime. We will produce the relevant monitoring records for any month Customer claims against, on request.

We measure the two components separately because they fail separately. A dashboard outage does not stop printed codes resolving, and a customer whose codes kept working all month should not be told that an unrelated outage was averaged into their number.

Credits are applied to the next invoice. Customers on annual billing receive the credit against the monthly-equivalent value of their subscription — the annual Fee divided by twelve. Credits have no cash value, are not refundable, are not transferable between workspaces or customers, and are not exchangeable for a refund or set-off against any other amount owed.

To receive a Service Credit, Customer must notify us at support@pixelqode.com within thirty (30) days of the end of the affected month. The request must identify the affected component and the dates and times of the Downtime claimed. Failure to comply forfeits the right to that credit.

We will not require Customer to prove the outage. If the monitoring records show the component was down, the credit is issued without argument.

The aggregate maximum Service Credits issued for all Downtime, across both components and all incidents, in a single calendar month shall not exceed 50% of Customer’s monthly-equivalent Fee for that month. Credits for separate components or separate incidents in the same month are not cumulative beyond that ceiling.

• Customer’s account must be current on all undisputed invoices both when the claim is made and when the credit is applied.
• No Service Credit is payable on a free plan, a trial, an evaluation or proof-of-concept workspace, or any plan listed above as provided without an uptime commitment.
• A Service Credit is the sole and exclusive remedy for Downtime and does not entitle Customer to terminate for cause, to damages, or to any refund of Fees already paid.

The redirect that resolves a scanned dynamic code is part of the Covered Service. We operate it ourselves, on the same global edge network that serves the application, in hundreds of locations — there is no third party between a customer’s printed code and its destination. Many QR services exclude the redirect from their SLA precisely because someone else runs it; we can include it because nobody else does.

The redirect is also deliberately independent of the rest of the product: an outage of the dashboard does not stop printed codes resolving, and scan recording happens after the visitor has already been redirected, so it can never slow a scan down.

Static QR codes sit outside uptime altogether, in the customer’s favour: they encode their destination directly, resolve without contacting any server, and cannot be taken down by an outage at us or at anyone else.

This SLA does not apply, and no Service Credit is payable, where unavailability or a failed scan is caused by any of the following. Time attributable to these is not counted as Downtime.

• Customer’s own domain and DNS. Any unavailability of a branded domain or hostname Customer controls, including expiry, non-renewal, transfer or lock; registrar, nameserver or DNS-provider outage; misconfiguration, deletion or alteration of the CNAME and verification records we require; DNS propagation delay; CAA or DNSSEC records preventing certificate issuance or validation; or the domain being blocked, throttled, flagged or filtered by any browser, security vendor, registry, network, messaging platform or reputation service. Our own short-link domain continues to resolve the same codes throughout.
• Destination URLs and Customer content. The website, file, form, storefront or landing page a code points to being unavailable, slow, moved, deleted, geo-restricted, rate-limited, requiring a login, or flagged by a browser or security vendor. Our obligation is to deliver the redirect response; what happens after the visitor arrives at Customer’s destination is Customer’s.
• Customer’s configuration and account state. Codes paused, archived, deleted, expired, password-protected or restricted by rules Customer set; an incorrect or mistyped destination; exceeding the limits, quotas or documented rate limits of Customer’s plan; and suspension for non-payment or for breach of the acceptable use policy.
• Printed artwork and scanning conditions. A code that cannot be read because of the size it was printed at, insufficient contrast or quiet zone, print resolution, ink bleed, damage, glare, lamination, shrink-wrap, curved or textured surfaces, obstruction, lighting, viewing distance, or artwork altered, recoloured, cropped or regenerated after export from PIXELQODE. Scannability is a property of the printed artefact, not of service availability — check it before a print run with our free scannability checker and print-size calculator.
• The scanning device, app or network. The end user’s phone, camera, QR reader, operating system or browser; and any network between them and us, including mobile carriers, captive portals, corporate proxies and firewalls, VPNs, content filters, and DNS resolution failures or interception at the visitor’s own resolver or ISP.
• Customer’s equipment, software and credentials. Customer’s own hardware, software or network; third-party equipment or services not within our primary control; compromised Customer credentials or API keys; actions taken by Customer’s users, contractors or agents; and protective measures we reasonably take in response to abusive, unlawful or excessive traffic originating with Customer.
• Maintenance. Scheduled maintenance, where we have given at least 48 hours’ notice by email — we schedule it outside business hours and aim for under 30 minutes per quarter — and emergency maintenance reasonably required to address a security vulnerability, data-loss risk or imminent failure, which we will notify as soon as practicable.
• Beta and preview features identified as such, and any feature Customer is using outside its documented purpose.
• Factors outside our reasonable control. Internet or network failures beyond our infrastructure, denial-of service attacks, acts of government or regulator, strikes, and events of force majeure.

The list above is long because most of what can stop a printed code from working sits outside our infrastructure. So it is worth stating plainly what stays inside it:

• Our infrastructure providers are our responsibility. If the cloud platform we run on has an outage that takes the Covered Service down, that is our Downtime and it is credited. We do not exclude “third-party hosting” — an exclusion that would quietly cover nearly every outage a service like this ever has.
• Our own defects are our responsibility. A bug we shipped, a bad deployment, a failed migration, a certificate we let expire or capacity we failed to provision are all Downtime.
• The redirect is in scope, not carved out. The part your printed codes actually depend on is the part we commit to.

Separately from uptime, we commit to these first-response times to support requests sent to support@pixelqode.com during business hours in Kolkata, West Bengal, India:

A first response is a human reading the request and telling you what happens next, not an automated acknowledgement. Business hours are 09:00–18:00 on working days in Kolkata, West Bengal, India; a request arriving outside them starts its clock when they next open. Where a plan includes a phone channel, the number is in your account. A missed first-response time is not itself grounds for a Service Credit.

Scan history is kept for the period stated on your plan and then deleted. This is a deletion, not a display limit: the underlying scan records are removed, so they cannot be recovered afterwards or produced on request.

Lifetime scan totals per code are not affected — they are counters rather than records of individual scans, and they survive the detail ageing out. If you need history beyond your plan’s window, export it before it lapses or move to a plan that keeps it for longer.

We may update this SLA. Where a change reduces the commitment, it takes effect at Customer’s next renewal rather than immediately, and we will give at least 30 days’ notice by email.