Status & uptime
The public status page shows live status, incident history and 90-day uptime for the web app, the API and scheduled jobs & webhooks.
The public status page is status.processcart.com. It shows live status, the incident history and 90-day uptime for each component:
| Component | What it covers | How it is checked |
|---|---|---|
| Web app | app.processcart.com — the member app, guest pages and kickoff forms |
An HTTPS check of the app, continuously |
| API | /api/ |
GET / — the unauthenticated probe that reports ok (200) or degraded (503) |
| Scheduled jobs & webhooks | The background workers that deliver webhooks, send email and run the due-date scanner | A heartbeat the due-date scanner sends on every run |
An incident is opened when a monitor fails and closed with a note when it is resolved; the history stays on the page.
Reading an incident from your side
- A failing
GET /v1/health(503degraded) means the database did not answer in time. Until it recovers, a request that needs it answers 503unavailablewithRetry-Afterwhen the connection is refused or dropped — or, when the database stalls rather than refusing, may take long enough to time out. Retry with backoff; a 503 is never stored for idempotent replay, so retrying with the sameIdempotency-Keyre-executes. - Webhook deliveries that fail during an incident on your side are retried on the published schedule (Webhooks); an incident on our side delays dispatch but loses no delivery — the outbox is durable.
- Every response carries
X-Request-Id; quote it when reporting a problem.