Audit · Plans and data
Troubleshooting
Most problems show in two commands on your app's server. Each one below starts with what you see.
Start with audit:ship --status
php artisan audit:ship --status
php artisan audit:shipThe first says how many events wait in the outbox, since when, the last error and what Audit refused. The second sends what waits and says how many events Audit kept, or why it stopped. Their words lead to one of the sections below.
Nothing arrives
The project's Overview in Audit is still the setup guide, or no new events show.
- Events wait, the oldest for longer than a minute or two: the scheduler isn't running. Start
php artisan schedule:work, or cron withschedule:run, on one of the app's servers.php artisan schedule:listshowsaudit:shipwhen the SDK added it. - Nothing waits: no event was written. Check that the code that calls
Audit::record()runs and its transaction commits, and thatMYBEAST_AUDIT_ENABLEDisn'tfalseon that server. audit:shipsays why it stopped: see the sections below.
When your app caches its config (php artisan config:cache), a change to .env counts only after you cache it again.
Not sending: the URL or the secret
Not sending: MYBEAST_AUDIT_URL or MYBEAST_AUDIT_SECRET is missing or malformed. Events wait in the outbox.The SDK sends nothing until both lines are in the server's .env: MYBEAST_AUDIT_URL=https://services.my-beast.com/audit, and the whole server secret, from sk_ to its end, with nothing around it. Events are safe in the outbox meanwhile.
The service does not know this secret
The service does not know this secret (401): check MYBEAST_AUDIT_SECRET.Audit answered 401: the secret was revoked, belongs to another product or another project, or was copied wrong. Make a new server secret in the project's Settings in Audit, under Audit keys, put it in the .env and run audit:ship again. Nothing was lost: the events waited.
An event was refused
1 refused by the service:
customer.viewed: occurred_at is in the future: check the host's clock.Audit took the events around it and gave this one's reason. The SDK keeps it aside in the outbox, logs an error, and never sends it again as it is. Fix the cause: in your code for the next events, and on the server for the ones waiting, such as its clock. Then put the refused events back in line:
php artisan audit:ship --retry-refusedAn event refused for what it holds is refused again as it is. It stays in the outbox, where --status keeps listing it.
occurred_at is in the future
Audit refused an event with this reason: the server that recorded it has a clock more than 5 minutes ahead of Audit's. Set its clock by NTP, then run php artisan audit:ship --retry-refused: once the clock has caught up with those events, they are kept, in their old place.
InvalidAuditEvent in your app
Audit::record() threw MyBeast\Audit\Laravel\Events\InvalidAuditEvent, and the action rolled back with it. The message names the part that is wrong: an email address where an id goes, an id with other characters, an action not in lower case, a context that is a list, too deep or too big. When an event is wrong lists each one.
A record stayed when its action rolled back
The outbox is on another database connection than the action's transaction, so its row committed on its own. Set MYBEAST_AUDIT_CONNECTION to the connection of the actions you record, and call Audit::record() inside the same DB::transaction() as the action.
Audit stopped taking events
audit:ship stops with The service answered 402 or The service answered 403, and Audit's message after it:
- 402: the project's subscription ended. Renew it on the workspace's Subscription page at id.
- 403: the project doesn't have Audit. Add it on the workspace's Subscription page at id, or use the secret of the project that has it.
Events wait in the outbox meanwhile and go, oldest first, once Audit takes them again.
Another audit:ship is running
Another run holds the lock, on this server or one that shares its cache, so this one sent nothing: two runs would send the same events. That is normal when you start one by hand while the scheduler's runs. When a run was killed half-way, its lock lets go after 10 minutes. The scheduler keeps a lock of its own for a task that never ended; php artisan schedule:clear-cache clears it.
The log is not whole
The Integrity page says Broken at an event. Leave the rows as they are and follow If it is ever not whole.