Axiom

What could Axiom show about a failed booking?

A bike shop’s website says it received a booking request, but the appointment never appears in the shop’s calendar. If the app and the service that saves bookings both record what they did, you can search their records together in Axiom.

A log entry is a timestamped note about one step. A structured entry puts details into named fields, such as the step, its outcome and a random label for that attempt. For example, the app might record that it accepted the request, while the booking service records that the slot had already been taken. The notes give you a place to look. Your app still has to record the steps and decide how to handle a failure.

What should you keep out before sending logs?

Choose a short list of fields before enabling any connection. For the booking rehearsal, send a timestamp, a random attempt label, the step and an outcome from a fixed list.

Keep names, email addresses, IP addresses, cookies, tokens, form contents and raw error messages out of this stream. Record an operation name instead of a full URL or path. Use made-up data in a private test copy and inspect what it would send before turning on forwarding. Axiom can hide text in query results after it receives the record. The check at the source keeps the original value from reaching it.

If you use Axiom’s standard Vercel connection, Axiom chooses the log sources when it installs the connection. The dashboards cannot change that source list afterward. Denied firewall requests can include a request path and the client’s IP address. Leave that connection off if its fields exceed what you’ve approved. You can send a smaller set of records directly from your server.

How do you find the notes for one attempt?

Create a test dataset, a collection for related log entries. Give each server that sends records a credential limited to sending them to that dataset. Keep it in the server’s protected settings.

In the test copy, have the app and booking service put the same random label on their entries. After the outgoing fields pass the privacy check, confirm that the booking service writes only to test records and a test calendar, and that notifications are disabled or go only to a recipient you control. Only then run a made-up booking that reaches the service and fails. If you cannot confirm those destinations, send two made-up log entries with the same label without submitting a booking. In Axiom’s Query Builder, pick the dataset and the time of the test. Filter for the exact label and read the notes by timestamp. Confirm that both steps appear and the received records contain only the approved details.

How could you notice repeated failures?

An Axiom monitor can check a condition on a schedule, such as whether the number of failed saves crossed a threshold. Start with a test monitor showing no active alert. Generate enough made-up failed saves within one monitored time window to cross the threshold. After the monitor runs, confirm that the alert reaches a destination you control.

Start with a condition that warrants a response, such as a run of failed saves. Keep expected cases, such as a customer choosing a slot that has just been taken, separate from faults that stop bookings. The monitor can act only on the records it can query.

What do the plan limits measure?

Axiom counts data arriving, work spent searching it and data kept for later as separate resources. One busy booking flow can use them at different rates.

Axiom Cloud has a monthly platform fee and charges for usage above its included allowances. Axiom documents that when an applicable spending limit stops further query work, searches and monitors can pause while records still arrive under a separate loading allowance. Check usage by resource if the records seem to have gone quiet.

What log records can you take with you?

You can download the results of a query as CSV or JSON. Set the time range and fields you need, then open the downloaded file and confirm that the expected rows are there.

That download covers the results returned by the query. Export important evidence before it ages out, and keep the field names, alert conditions and destination settings you would need to rebuild the setup elsewhere. Restrict access to the exported file just as you would to the dataset.