Service level agreement
What this document commits to
This page states the service levels Omega Point Solutions LLC commits to across its hosted products — FraudTrax, Stolen Vehicle Tracker, Hatchet Trace, DAN-O Desk, Omega Guard, Omega Lens, Omega Point DTX, and the Threat ID sensor. It sets out how we classify an incident, how fast we respond, when we perform maintenance, and how availability is measured.
Where a signed contract, task order, or purchase agreement states different terms, that document governs. This page is the default, not a ceiling — we will negotiate firmer terms, including service credits and a named availability commitment, as part of a specific engagement.
Availability: what we measure, and what we do not yet claim
We do not publish an availability percentage, and that is deliberate.
An uptime figure is only meaningful if it comes from continuous measurement that the vendor can produce on request. We are standing up that measurement now — independent synthetic checks against every production surface, recorded to a retained log we control. Until a full trailing twelve-month window exists behind it, publishing a number would mean asking you to trust a figure we could not evidence. We would rather tell you that plainly than print the figure the category expects and hope nobody asks how we got it.
When the measurement window is complete we will publish the measured figure together with its methodology — what was probed, from where, at what interval, and what counted as a failure. Until then, the commitments below are the ones we make, because they are the ones we keep by acting rather than by asserting.
If you need a contractual availability commitment before then, ask. We will agree one in writing for the specific product and scope in question.
Infrastructure we depend on
Our products run on Cloudflare's global edge network — Workers for compute, D1 for relational data, R2 for object storage, and KV for configuration. Static properties are served from the same edge. This is a deliberate architectural choice: there is no single origin server whose failure takes a product offline, and no data centre whose loss is ours alone to recover from.
It also means part of our availability is inherited. We do not warrant the availability of the underlying platform, and we do not present its published figures as ours. What we own is everything above it: our code, our data, our configuration, our response.
Incident severity
| Severity | Definition |
|---|---|
| Sev 1 — Critical | Production service is unavailable or unusable for all users, or data integrity is at risk. No workaround exists. |
| Sev 2 — Major | A core function is unavailable or materially degraded for many users, or a single customer is fully blocked. A workaround may exist but is not sustainable. |
| Sev 3 — Minor | A non-core function is impaired, or a defect affects a limited set of users with a reasonable workaround available. |
| Sev 4 — Request | Question, configuration change, enhancement request, or cosmetic defect. No functional impact. |
Severity is assigned on impact, not on who reported it. If we disagree with your assessment we will say so and explain why — we will not silently downgrade a ticket.
Response and restoration targets
The clock starts when a report reaches us by the channels below, or when our own monitoring detects the condition — whichever comes first.
| Severity | Acknowledge | Status updates | Restoration target |
|---|---|---|---|
| Sev 1 | 1 hour, 24×7 | Every 2 hours until resolved | Continuous effort until service is restored |
| Sev 2 | 4 business hours | Daily | 2 business days |
| Sev 3 | 1 business day | Weekly | Next scheduled release |
| Sev 4 | 2 business days | On change | Prioritised on the roadmap |
Business hours are 08:00–17:00 US Central, Monday to Friday, excluding US federal holidays. Sev 1 acknowledgement is not limited to business hours.
Restoration is not the same as root cause. Restoring service comes first; the permanent fix follows. For any Sev 1, we provide a written post-incident summary within five business days covering what happened, the impact and its duration, what was done, and what changes prevent a recurrence.
Reporting an incident
- Sev 1 and Sev 2: email support@omegapointsolutions.com with the severity in the subject line. Contracted customers also receive a direct escalation number at onboarding.
- Sev 3 and Sev 4: the same address, or through the in-product support link.
Include the product, what you were doing, what you expected, what happened instead, and the approximate time. If it affects specific records, tell us which — but never send criminal-justice information, personally identifiable information, or credentials by email. We will arrange a secure channel for anything sensitive.
Maintenance
Scheduled maintenance is performed Sundays 02:00–06:00 US Central. We announce anything expected to interrupt service at least five business days in advance. Most releases are deployed without downtime and are not announced as maintenance.
Emergency maintenance — a security patch or a fix for an active incident — may be performed at any time. We notify affected customers as soon as practicable, and always within 24 hours. A security fix will not be delayed to fit a maintenance window.
Announced maintenance is excluded from availability measurement. Emergency maintenance is not.
What these commitments do not cover
- Failure of the customer's own network, hardware, browsers, or identity provider.
- Third-party services outside our control, including the underlying cloud platform, payment processors, and external data sources we integrate with on your behalf.
- Use of a product outside its documented purpose, or configuration changes made by the customer against our written guidance.
- Beta, preview, evaluation, and demonstration environments, which carry no service level.
- Force majeure.
Where an external dependency causes an outage, we will still respond on the timetable above, keep you informed, and pursue the provider. We simply cannot commit to a restoration time for a system we do not operate.
Security and data handling incidents
A suspected security incident is treated as Sev 1 from the moment it is suspected, not from the moment it is confirmed. Our notification obligations, breach handling, and evidence practices are set out on the security page; contractual notification timelines in a signed agreement take precedence over the targets on this page.
Changes to this page
We may update these service levels. Material reductions will not be applied to an active contracted engagement without written agreement. The date at the top of this page reflects the last revision.