Skip to content

Audit & spend caps

Two features keep AppGantry accounts boring and predictable:

  • The audit feed records every meaningful action that happened in your org, with the who, what, when, and from-where.
  • Spend caps let you set a monthly ceiling on metered usage and decide what happens when it's reached.

The audit feed

Every org gets an audit feed. It's append-only, scoped to a single organization, and partitioned by UTC day so it stays fast at any volume.

What it records

A non-exhaustive list of events:

Event When
auth.login A developer logs in.
auth.failed_login Wrong password / unknown email.
auth.pat_created A personal access token is minted.
auth.pat_revoked A PAT is revoked.
auth.project_access_token_created A project access token is minted.
auth.project_access_token_rotated A project access token's secret is rotated.
auth.project_access_token_revoked A project access token is revoked.
org.member_invited A new member is invited.
org.member_role_changed A member's role changes.
project.created A new project is created.
build.uploaded An upload completes successfully.
build.deleted A build is removed (GC or manual).
tester.invited An install invitation goes out.
byosa.diagnose The BYOSA self-test runs.
byosa.config_changed Operator-side flip to/from BYOSA.

Each row carries the actor (developer, personal access token, or project access token), source IP and user-agent where applicable, and a structured payload of the event-specific fields.

What it does not record

  • Tester downloads. Those are counted by the download meter but not stored as individual audit rows (volume would dominate everything else on a viral build).
  • Read-only API calls. The audit feed is for actions that change state or assert identity, not for every GET.

Retention

Plan Default audit retention
Team 90 days
Business 12 months
Enterprise Coming soon

Audit-feed export to your own SIEM is on the Enterprise roadmap.

Reading the feed

In the web app, Org → Audit shows a day-paginated view with filters on event type, actor, and IP. Programmatic access is via GET /api/v1/organizations/{org_id}/audit?day=YYYY-MM-DD.

The endpoint returns one UTC day at a time. Paginating across days client-side keeps the server pages small and the response bounded.

Spend caps

A viral build multiplied by thousands of testers can move a lot of bytes in a single afternoon. AppGantry ships two mechanisms to bound that:

Budget alerts

A budget alert notifies the org owner (by email) as your monthly metered spend approaches a configured threshold. Defaults are 50% and 90% of the current month's projected total; you can add custom thresholds.

Alerts don't block anything. They just give you a heads-up so you can react before the cap engages.

Hard spend cap

A hard spend cap is an explicit upper bound on metered usage for the billing month. When the cap is reached:

  • New uploads and downloads are blocked with HTTP 402 Payment Required.
  • Existing artifacts continue to accrue storage for the rest of the month. There's no automatic delete. You're billed for the bytes you're already holding.
  • Metadata reads (the audit feed, build list, tester list) still work. The cap blocks byte movement, not visibility.

Cap behaviour per plan

Plan Cap available Cap default
Team Pre-paid balance acts as cap; configurable $0 balance = 402
Business Optional hard spend cap None (uncapped); you set one if you want one
Enterprise Coming soon -
BYOSA orgs N/A Your cloud provider is the ceiling

What 402 looks like

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "error": {
    "code": "spend_cap_reached",
    "message": "Monthly spend cap of $250.00 has been reached. Adjust the cap in org settings or wait until the next billing period.",
    "billing_period_end": "2026-07-01T00:00:00Z"
  }
}

Adjust the cap, top up the prepaid balance (Team), or wait for the next billing period to begin.

For most teams:

  1. Set a hard cap a few × your typical monthly bill. High enough to absorb a busy month, low enough to catch a runaway.
  2. Set budget alerts at 50% and 90% of that cap.
  3. Migrate to BYOSA if your hosted bill is consistently above the Business platform fee ($100/mo). The BYOSA path removes the per-MB risk entirely.

See also