Service status and incident communication

GraphJSON does not currently publish an automated public status feed, public availability SLA, guaranteed ingestion-freshness objective, recovery-time objective, or recovery-point objective.

This page explains how to recognize a possible service incident, what GraphJSON can communicate today, and how to keep your application safe while an analytics dependency is unavailable.

Current public status boundary#

“No published guarantee” does not mean GraphJSON expects failure. It means a customer should not convert ordinary observed behavior into a contractual promise.

Recognize a possible incident#

First rule out one-workspace causes:

• expired session
• invalid or replaced API key
• wrong collection or workspace
• event timestamp outside the visible range
• retention expiration
• a recent producer or query deployment
• malformed data
• a provider integration change

Suspect a broader incident when:

• several unrelated, previously working endpoints fail
• multiple team members see the same failure
• ingestion and queries fail across collections
• retries across a reasonable interval produce the same server-side error
• no account, key, deployment, or payload change explains it

Do not create a traffic spike by retrying continuously to determine whether an incident is still active.

Preserve application behavior#

Analytics should remain off the critical path:

customer action
  ├─ commit authoritative product state
  ├─ enqueue analytics event
  └─ return product response

delivery worker
  ├─ send bounded batches
  ├─ retry recoverable failures
  ├─ preserve event_id and occurrence time
  └─ alert on queue age and dead letters

During a GraphJSON disruption:

• keep important events in a durable queue
• cap retry concurrency
• use exponential backoff with jitter
• preserve original occurrence timestamps
• keep a stable event_id
• show an unavailable embed state distinct from empty data
• keep the customer’s primary product workflow usable

Never switch financial, authorization, entitlement, or inventory decisions to an analytics query during an incident.

Report a suspected incident#

Email hi@graphjson.com with:

subject: Possible GraphJSON incident — <short symptom>

workspace:
approximate start time:
time zone:
affected endpoint or surface:
affected collection:
HTTP status:
redacted error:
scope:
last known success:
retry count and outcome:
application event_id:
recent change:

Send one representative error, not a stream of repeated messages.

Never include:

• API key
• password, reset link, session token, or SMS code
• complete private event payload
• full personalized embed URL
• payment-card information

Communication during an incident#

Until an automated status feed exists, support communication is the current public path.

A useful GraphJSON incident update should distinguish:

1. Investigating — symptoms are acknowledged and scope is being determined.
2. Identified — a cause or affected component is known.
3. Mitigating — a corrective action is in progress.
4. Monitoring — service is recovering and being observed.
5. Resolved — the incident is no longer active.

Customers should ask for the affected surface, approximate start and recovery time, data-delivery implications, and any required replay or reconciliation action.

After recovery#

Do not assume queued data is complete merely because requests succeed again.

1. drain queues with bounded concurrency
2. preserve original timestamps
3. keep the same event IDs across retries
4. compare event counts by type and time window
5. inspect rejected and dead-lettered events
6. verify critical dashboards and embeds
7. confirm alerts have enough completed data
8. document any permanent gap

For an uncertain timeout window, deduplicate by stable event_id.

Planned maintenance#

GraphJSON does not currently publish a universal maintenance calendar or customer notification subscription.

For a business-critical launch, migration, or high-volume backfill, contact GraphJSON in advance with:

• date and time zone
• expected event rate and payload size
• expected query or embed traffic
• required freshness
• rollback plan
• operational contact

Advance coordination is not an availability guarantee, but it gives both teams a defined communication path.

Internal readiness checklist#

• Product transactions do not depend synchronously on analytics.
• Important events enter a durable queue.
• Retries are bounded and jittered.
• Event IDs survive retries.
• Queue age and dead letters are observable.
• Embeds have loading, empty, and unavailable states.
• Support metadata can be collected without secrets.
• Critical totals can be reconciled with the system of record.
• A GraphJSON incident contact is recorded.

Pair this page with Service behavior and operational expectations, Reliable event delivery, and the troubleshooting hub.