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.
Recommended setup¶
For most teams:
- Set a hard cap a few × your typical monthly bill. High enough to absorb a busy month, low enough to catch a runaway.
- Set budget alerts at 50% and 90% of that cap.
- 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¶
- Plans & pricing: the meters spend caps cap.
- BYOSA: the way to remove per-MB risk entirely.