Sign in →
1 min read

Operations — Overview

Reliability and integration. The public status page (service status, incidents, maintenance, API status), payment reconciliation and ERP sync, and internal metering health + event log.

Updated 2026-07-29Suggest edits

Operations is where you keep the platform honest and prove it. The public status page tells customers what's up and what's not; Payment Reconciliation and ERP Sync keep the money and the books aligned; Metering Health and Event Log answer "is anything broken right now?". This is the section your on-call opens first when a customer reports something looks off.

What Operations is for#

Three clusters. Public reliability — Service Status, Incident Manager, Scheduled Maintenance, and API Status all publish to the status page your customers visit. Integration & money — Payment Reconciliation (gateway → ledger match) and ERP Sync (invoices pushed to QuickBooks / Xero / NetSuite). Internal observability — Metering Health (per-billable-unit aggregate signals) and Event Log (every platform event, searchable + streamable).

INFO
The reliability cluster is the one part of Operations your customers actually see — the status page is public. Everything else here is operator-only. The outbound billing alerts customers subscribe to (invoice generated, usage threshold reached) are configured under , not here.

Pages in this section#

Service Status
Operator config for the public status page. Monitors per service, uptime + response-time history, alert rules, and the API Endpoints tab.
Open
Incident Manager
Declare, update, and resolve incidents. Updates render live on the public status page. Postmortem editor for the writeup afterwards.
Open
Scheduled Maintenance
Pre-announce maintenance windows with affected services. Subscriber email + an on-page banner before and during the window.
Open
API Status
The per-endpoint health view inside Service Status — the individual API operations your customers call, not just whole services.
Open
Payment Reconciliation
The daily reconciler’s review queue. Compares Aforo’s record of each payment against the gateway and surfaces divergence to resolve.
Open
Event Log
Searchable + filterable + SSE-streamable feed of every platform event. Severity filter, time-range, JSON detail drawer.
Open
Metering Health
Per billable unit: events/24h, error rate, last-event-at, anomaly strip. NO_DATA cards for declared-but-quiet units before they corrupt billing.
Open
ERP Sync
Push finalized invoices to QuickBooks / Xero / NetSuite / Custom Webhook. OAuth or token auth, idempotent re-sync, retry on failure, sync log.
Open

A simple incident playbook#

When a customer reports "billing looks wrong" or "events aren't arriving," walk the section in this order:

1
Event Log — search the customer + a recent timestamp
If events are landing at all, you’ll see them here. Severity filter shows ERROR / CRITICAL in red.
2
Metering Health — is the relevant billable unit DOWN, DEGRADED, or NO_DATA?
NO_DATA means the unit is declared but no events arrived in the window — usually an SDK / gateway misconfiguration upstream.
3
Payment Reconciliation — does the money match?
Confirms what landed in your gateway matches what Aforo billed; flags orphaned charges and unsettled refunds.
4
ERP Sync — did the invoice reach the accounting system?
The sync log surfaces per-invoice failures with the ERP-side error and a one-click manual retry.
5
Service Status / Incident Manager — is this bigger than one customer?
If multiple customers are affected, declare an incident so the status page tells the story before your inbox does.
  • — the outbound billing/usage alerts customers subscribe to.
  • Intelligence → Usage Ingestion — the read view on the same metering pipeline that Metering Health monitors.
  • Protocols → Webhook Ingestion — the inbound mirror of outbound alerts (events FROM third parties).
  • Intelligence → Margin Guard — margin policy that causes alerts; this section is where the reliability signal lands.