GraphJSON does not currently publish an automated live-status feed or availability SLA. This page documents the present support path and the information needed to investigate a possible service incident. It must not be interpreted as a real-time "all systems operational" signal.
Last reviewed July 2026.
Current status-reporting boundary
| Capability | Current public availability | | --- | --- | | Automated public status feed | Not currently published | | Availability SLA | Not currently published | | Guaranteed ingestion-to-query delay | Not currently published | | Public RTO or RPO | Not currently published | | Customer-selectable backup restore | Not available | | Incident contact | hi@graphjson.com |
For compatibility and planned API behavior, review the API changelog.
Before reporting an incident
Rule out a workspace-specific problem:
- confirm the API key and workspace
- confirm the collection and event timestamp
- remove chart filters and widen the range
- check the latest application or query deployment
- check provider-integration delivery
- retry once with a bounded timeout
Use the troubleshooting hub for a symptom-led diagnosis.
Report a possible incident
Email hi@graphjson.com with:
- workspace name
- approximate start time and time zone
- affected endpoint or product surface
- collection
- HTTP status and redacted error
- one request, one producer, or the whole workspace
- last known success
- retry count and outcome
- recent deployment or configuration change
Never include an API key, password, SMS code, complete private payload, payment-card information, or full personalized embed URL.
Keep your application safe
Product transactions should not depend synchronously on analytics availability. Commit the authoritative business state first, place important events in a durable queue, and deliver them with stable event IDs, original timestamps, bounded batches, and jittered retries.
Customer-facing embeds should have separate loading, empty, and unavailable states. A GraphJSON failure must not prevent a customer from using the primary product workflow.
After recovery, reconcile queued events and critical totals with the system of record.
The full incident workflow is documented under Service status and incident communication.