Status & Incident Communication

Last Updated: July 25, 2026

This page explains how we report on the health of our Services, what you can expect from us during an incident, and how to reach us when something is broken.

Index

Live Service Health
Incident Severity
How We Communicate
Update Cadence
Model Provider Incidents
Security Incidents
Post-Incident Reviews
Maintenance
Reporting a Problem

1. Live Service Health

A live health indicator is shown in the site footer. It reports one of three states:

| State | Meaning | | --- | --- | | Operational | Our API is reachable and its dependencies are healthy | | Degraded | The health check is failing or the API cannot be reached | | Checking | The health check is in progress |

The indicator reflects a real-time check against our API rather than a manually updated page, so it can detect a problem before we have. It reports on our own platform: a healthy indicator does not guarantee that every model provider is available.

2. Incident Severity

We classify incidents by customer impact:

| Severity | Meaning | Examples | | --- | --- | --- | | Critical | Service unavailable, or data at risk | Full outage, authentication failure, data integrity issue, security incident | | Major | A core capability is unusable | Generation failing across models, uploads failing, billing unavailable | | Minor | Degraded but usable | Elevated latency, one model unavailable, delayed processing | | Maintenance | Planned work | Scheduled deployment or infrastructure change |

3. How We Communicate

Depending on severity, we use:

The health indicator, which reflects platform reachability automatically
In-product notices for incidents affecting active users
Email to administrators for Critical and Major incidents, and for scheduled maintenance
Direct contact with enterprise customers through the channel in their agreement

We aim to acknowledge a Critical incident publicly within 30 minutes of confirming it, even when we do not yet know the cause. We would rather tell you we are investigating than say nothing while we work.

4. Update Cadence

Once an incident is declared, we update until it is resolved:

| Severity | Update frequency | | --- | --- | | Critical | Every 30 minutes | | Major | Every hour | | Minor | Every 4 hours, or on material change |

Each update states what we know, what we are doing, and when the next update is due. When there is no news, we say so rather than going quiet.

We declare an incident resolved only after the fix is verified in production, and we say so explicitly.

5. Model Provider Incidents

Many capabilities depend on third-party model providers. When a provider fails, generation using its models may queue, slow, or fail while the rest of the platform is healthy.

In that situation we will report which capability is affected, route to an alternative model where a suitable one exists, and restore credits consumed by failed generations.

We depend on providers for information about their own incidents, so our updates may lag theirs. Provider outages are excluded from the uptime calculation in Service Levels.

6. Security Incidents

Security incidents follow the process in our Security Policy.

Where an incident affects personal data, we notify affected customers and the relevant supervisory authorities within the timeframes required by applicable law. Enterprise customers are notified within 48 hours under our Data Processing Addendum.

We may withhold specific technical detail while an incident is active where publishing it would increase risk to customers. We publish it afterwards.

7. Post-Incident Reviews

For every Critical incident, and for Major incidents with significant impact, we publish a review within 5 business days covering:

What happened, and the timeline
Who and what was affected, and for how long
The root cause
Why detection or recovery took as long as it did
What we are changing, with owners

We write these to be useful rather than reassuring. Where we made a mistake, the review says so.

8. Maintenance

Scheduled maintenance requiring downtime is announced at least 72 hours in advance to administrators, and scheduled in a low-traffic window where possible.

Emergency maintenance may occur without notice where necessary to address a security vulnerability, prevent data loss, or respond to a critical failure. We explain it afterwards.

Full terms are in Service Levels.

9. Reporting a Problem

If you are experiencing a problem we have not reported, tell us. Customer reports frequently detect issues before our monitoring does.

Email: support@inferon.ai

Include what you were doing, what happened instead, when it started, any error message or request identifier, and whether it is still happening.

Security vulnerabilities: security@inferon.ai, under our Security Policy
Billing effects of an incident: billing@inferon.ai
Enterprise customers: use the channel in your agreement for Critical issues