Service Status

This page explains how we report availability, how we communicate during an incident, and what we commit to. It is a policy page, and it is deliberately honest about the fact that we do not currently publish a live automated status dashboard.

1. Live health endpoints

These endpoints are served by the application itself and reflect its real state. They are the fastest way to tell whether the Service is up.

The API is served only from the application host app.oraglegpt.org. The apex oraglegpt.org is the marketing and legal site and runs no API, so these paths return 404 there.

If /api/v1/health returns 200 and you still cannot use the Service, the problem is likely to be your connected social platform rather than GPTpost. Check section 5.

2. What we currently publish, and what we do not

We would rather state this plainly than imply a capability we do not have.

3. Incident severity

4. How we communicate during an incident

1. Declare. We declare an incident internally as soon as we confirm customer impact, rather than waiting to understand the cause.
2. Health endpoints. The endpoints in section 1 are the live signal, and they are what we point you at first. There is no in-product incident banner in this build, so do not wait for one.
3. Email, sent by hand. For a major or partial outage, we email workspace administrators from support@oraglegpt.org with what we know, what is affected, and what to do meanwhile. That message is written and sent by a person. The Service generates no email itself, so if our mailbox is part of the outage this step is delayed with it.
4. Update cadence. We update at least every 60 minutes during a major outage, even when the update is "still investigating". Silence during an outage is a failure of its own.
5. Resolve. We confirm resolution explicitly, in writing, rather than letting the last update be the last you hear of it.
6. Post-incident review. For a major outage we publish a summary to affected customers within 5 business days, covering what happened, the impact, the root cause, and what we are changing. We send it whether or not anyone asks.

If the incident is a personal data breach, the notification process in Security section 7 and Data Processing Addendum section 9 applies as well, including notification without undue delay and within 72 hours.

5. When the problem is a social platform, not us

A large share of publishing failures originate at the platform, not at GPTpost. The distinction matters because we cannot fix the platform's side.

The publication attempt log in the product records the exact request we sent and the exact response the provider returned. That log is the authoritative answer to "was it us or them", and it is why we retain it.

Each platform publishes its own status. We do not mirror those pages, because a stale mirror is worse than no mirror.

6. Planned maintenance

• We give advance notice of planned maintenance where it is practical, by email to workspace administrators, sent by hand from support@oraglegpt.org. There is no in-product maintenance notice in this build.
• We schedule maintenance for low-traffic periods where we can.
• Scheduled posts are not lost during maintenance. They are queued and published when the scheduler resumes, though they may publish later than the scheduled time.
• Emergency maintenance to close a security issue may happen without notice. We explain it afterwards.

7. Known capacity limitation

The database runs as a single primary with no high-availability cluster and no automatic failover. This is documented rather than hidden, in the Terms of Service section 10 and the Security page section 8. A restart of the database or of the API is a brief interruption, and recovery from a failure of that primary is a restore rather than a failover. It does not affect the confidentiality or the integrity of your data.

Write-ahead log archiving is enabled and backups are verified daily by restoring them into a clean environment, but recovery to an arbitrary point in time has not yet been rehearsed end to end, so no recovery-point or recovery-time objective is offered.

8. Subscribe to notifications

There is no automated notification list: the Service sends no email, so every notice on this page is sent by a person from support@oraglegpt.org to the workspace administrator addresses we hold. To add another address, or to receive subprocessor change notices as well, write to support@oraglegpt.org and we will add it to that list by hand and confirm.

9. Report an outage

The product will not tell you that an incident is open, so if you believe the Service is down, check https://app.oraglegpt.org/api/v1/health and then tell us at support@oraglegpt.org with:

• the time and time zone;
• the URL or action that failed;
• the X-Request-ID header value from the failing response, if you have it;
• whether https://app.oraglegpt.org/api/v1/health responds for you.

Suspected security incidents go to security@oraglegpt.org and are always treated as P1.

10. Related pages

GPT LLM ORAGLE Ltd. Liability Co.
30 N Gould St, Ste N
Sheridan, WY 82801
United States