Service Status
This page describes how to tell whether GPTpostLLM at https://app.oraglegpt.org is working, how we classify and communicate incidents, and what we do and do not promise about availability.
We would rather publish an accurate page with no numbers on it than an impressive one we cannot stand behind. So the honest position is stated first, in section 1, before anything else.
1. What we do not offer
- There is no uptime service level agreement. We do not publish an availability percentage, we do not offer service credits for downtime, and no figure anywhere in our documentation or in a sales conversation constitutes an availability commitment. Your rights if the Service is not fit for purpose come from the contract in Terms of Service and, for consumers, from Romanian consumer law as described in Consumer Rights and Dispute Resolution.
- There is no third-party status page. We do not use Statuspage, Pingdom, Better Uptime or any similar vendor, so there is no status.* subdomain to bookmark, no historical uptime graph, and no vendor-hosted incident timeline.
- There is no automated incident feed. No RSS feed, no webhook, no SMS broadcast, and no subscription list.
- There are no email notifications, for anything. The Service contains no mail client and sends no email at all, so it cannot alert you when something breaks. Do not build an operational process that depends on hearing from us automatically, because you will not.
Incidents are communicated by updating the status page at Service Status and by responding at contact@oraglegpt.org. That is the whole of it. If you need to know whether something is wrong right now, check the health endpoints in section 2 yourself, and write to contact@oraglegpt.org if the answer does not match what you are seeing.
2. Health endpoints you can check yourself
Two endpoints are exposed on the application. They return quickly, they require no authentication, and you may poll them at a reasonable interval.
| Endpoint | Question it answers | What a healthy response means |
|---|---|---|
/healthz | Is the process alive? | The application process has started and is answering HTTP. It says nothing about whether it can actually do any work |
/readyz | Can it serve requests? | The application has checked its dependencies, principally the database, and is ready to accept traffic |
The difference matters and it is the single most useful thing on this page.
GET /healthz -> 200 process is up
GET /readyz -> 200 process is up AND can serve
GET /healthz -> 200
GET /readyz -> 503 process is up but cannot serve, for example the
database is unreachable or a replica is still
warming up. Requests will fail even though the
process answersA 200 from /healthz proves almost nothing. A process can answer that endpoint while being unable to read a single row. If you are building a monitor, monitor /readyz. Treat a sustained non-200 from /readyz as an outage and tell us at contact@oraglegpt.org if we have not already published something here.
3. Incident severity
When something is wrong we classify it as follows, and the classification determines how quickly we work and how we describe it on this page.
| Level | Meaning | Typical example |
|---|---|---|
| SEV1, critical | The Service is unavailable, or data integrity is at risk, for all or most customers | Application down, database unreachable, /readyz failing across the board, a defect that could corrupt or expose data |
| SEV2, major | A core function is broken for many customers, with no workaround | Scheduled publishing not running, sign-in failing, media upload rejecting everything |
| SEV3, minor | A function is degraded or broken for some customers, or a workaround exists | One connector failing, slow page loads, an export that has to be retried |
| SEV4, cosmetic | Something is wrong but nothing is prevented | Display defect, wrong label, incorrect timestamp formatting |
Anything at SEV1 or SEV2 is written up on this page while it is happening, not only afterwards. SEV3 is noted here when it lasts more than a working day. SEV4 is fixed in the ordinary course and is not published as an incident.
A published incident entry states what is affected, when it started, what the current position is, and what to do in the meantime. When it is resolved we say so, and for SEV1 we add a short account of the cause and what changed as a result.
4. Telling our outage apart from a platform outage
This distinction causes more confusion than anything else in the product, so it is worth being precise.
The connectors are publish-only and they depend entirely on the destination platform's API. When you publish, we call the platform. If the platform's API is down, rate limiting us, rejecting the token, or rejecting the content, the publish fails. That failure originates there, not here.
Use this to work out where the problem is:
| What you see | Where the problem probably is |
|---|---|
/readyz returns non-200, the application will not load, sign-in fails | Ours. Report it at contact@oraglegpt.org |
| The application works, but every publish to one platform fails while others succeed | That platform, or the connection to it. Check the platform's own developer status and your account standing there |
| Publishing fails for one account on a platform while another account on the same platform works | That connection. The token has probably expired or been revoked. Reconnect the account |
| The platform accepted the post, and the post is live, but figures in the product look wrong | Not an outage. We never fetch figures from any platform. See section 5 |
| The platform restricted or suspended your account there | Between you and the platform. We cannot appeal or restore it. See Support |
We record the error the platform returned and surface it against the failed post, so the platform's own message is what you see rather than a generic failure.
Where a platform outage is broad enough that many of our customers are affected, we note it on this page as an advisory and label it clearly as an upstream problem rather than an incident of ours. We do not control it, we cannot fix it, and we cannot give an estimate for its resolution.
5. What is never an outage
- Missing analytics. No provider analytics are ever fetched. The only way analytics data enters the platform is your own authenticated request to
/api/v1/analytics/observations. If a figure is absent, nothing sent it. - Missing comments, mentions, replies or messages. The product has no inbox capability on any connector and never did. There is nothing to be down.
- Not being able to delete or edit a published post. No connector implements it. A live post can only be changed on the platform itself.
- Not receiving an email from us. The Service sends none.
- A connector you cannot connect. Only some providers can be connected on this deployment. If a provider offers no connection route here, that is its configured state, not a fault.
6. Planned maintenance
Most changes are deployed without interruption. Where a change requires a window in which the Service is unavailable or degraded, for example certain database migrations, we:
- Publish the window on this page in advance. We aim for at least 72 hours' notice for a planned interruption, and we aim to schedule it outside 08:00 to 20:00 Europe/Bucharest on working days.
- State what will be unavailable and for how long we expect it to be.
- Update this page when the work starts and when it finishes.
Scheduled posts due during a maintenance window are not silently dropped. The publishing pipeline uses a database-backed outbox, so work due during the window is picked up when the Service returns. A post may therefore go out later than its scheduled time. Where a destination platform rejects it as stale, that failure is recorded against the post.
Emergency maintenance, for example a security fix that cannot wait, is carried out without notice and published here as it happens.
7. How the Service is built, and what that means for failure modes
Being open about the architecture makes the failure modes predictable.
- PostgreSQL 18 is the single source of truth, behind PgBouncer for connection pooling. If the database is unavailable,
/readyzfails and the Service is down. There is no partial mode. - Caddy terminates TLS, with certificates from Let's Encrypt.
- There is no Redis and no message broker. Queued work lives in a database-backed outbox. Fewer moving parts means fewer independent things that can fail, and it means queued work survives a restart.
- Object storage is self-hosted on our own server, not a third-party cloud bucket. Its availability is ours to manage and ours to answer for.
- Hosting is Contabo GmbH, on servers in the European Union, in France and Germany. A failure in that provider's network or facility is visible as an outage here even though the cause is upstream. We will say so when that is the case.
- There is no CDN vendor holding customer data, no third-party analytics, and no third-party email vendor, so none of those can be a source of an incident.
The full list of processors is in Subprocessors. The security posture is described in Security.
8. Reporting a problem and getting an answer
Write to contact@oraglegpt.org. Include the time and time zone, what you were doing, the workspace, the exact error text if any, and whether /readyz was returning 200 at that moment. That last detail alone often halves the time it takes to answer you.
We respond during working hours, Monday to Friday, in Romanian or English. There is no phone support queue and no live chat; +40 753 980 299 is the company's registered telephone number published for legal identification under Legea 365/2002 art. 5, not a support hotline. Support sets out response targets and priority levels in full, and explains that targets are targets rather than guarantees.
If you are a consumer and you consider the Service was not provided as it should have been, Consumer Rights and Dispute Resolution explains your remedies and the Autoritatea Națională pentru Protecția Consumatorilor (ANPC) route, including the ANPC alternative dispute resolution channel at https://anpc.ro/sal/ and the complaints platform at https://reclamatiisal.anpc.ro.