DocsBeta

Access control

Access log

Review relay history and diagnose why an access attempt succeeded or failed.

Last updated 2026-03-28

The Access log is the detailed history of every trigger attempt for a relay. It is the primary reference for troubleshooting access problems and for auditing who used a relay and when.

What you see on this tab

Each entry in the access log represents one trigger attempt. The following information is shown for each entry:

  • Status -- whether the attempt was a success (relay opened) or a failure (relay did not open)
  • Date -- the calendar date of the attempt
  • Time -- the exact time the attempt was made
  • Relation -- the person (pilot or other user) who triggered the relay
  • Message or error -- additional context about the result, such as the reason for a failure

Successful entries confirm that the relay responded as expected. Failed entries include an error message that explains why access was denied, such as "outside geofence", "no valid booking", or "relay inactive".

When to use the access log

The access log is the first place to look whenever:

  • A pilot reports that a relay did not open
  • You need to confirm whether a specific person triggered a relay at a particular time
  • You want to verify that a configuration change is working correctly
  • You need an audit trail for security or operational review

How to troubleshoot a failed access attempt

  1. Open Access control and select the relay from the Relay list.
  2. Go to the Access log tab.
  3. Find the entry that matches the reported time and person. Compare the timestamp in the log with the time the user reported the problem -- small differences are normal, but large gaps may mean you are looking at the wrong entry.
  4. Read the status. If it shows success, the relay did open and the problem may be physical (hardware) rather than software.
  5. If it shows failure, read the error message carefully. The message tells you which condition was not met.
  6. Based on the error message, take the appropriate next step:
    • "Relay inactive" -- go to Configuration and check the active status
    • "Outside geofence" -- the pilot was too far from the relay location. Verify the geofence settings in Configuration or confirm the pilot's actual position
    • "No valid booking" -- the pilot did not have an active booking linked to this relay. Check whether the booking requirement should be enabled and whether the pilot's booking is correct
    • "Blocked by exception" -- the pilot has a block exception in Access exceptions. Review whether the block is still appropriate

How to verify a configuration change

After adjusting relay settings in the Configuration tab, you can confirm the change is working:

  1. Ask a pilot to trigger the relay, or wait for the next natural attempt.
  2. Return to the Access log.
  3. Find the new entry and confirm the status matches your expectation (success or failure depending on the change).

Common tasks

  • Investigate a "gate would not open" report -- find the matching log entry by time and person, read the error, then follow up in the relevant tab.
  • Audit relay usage for a date range -- scroll through the log and note all entries within the period. Look for patterns such as repeated failures or unexpected users.
  • Confirm a pilot used a relay -- search the log for the person's name and check the timestamp and status.

Good practice

  • Always compare the reported time of the problem with the actual timestamp in the log before drawing conclusions. Pilots sometimes estimate times inaccurately.
  • Use the access log as your primary troubleshooting reference. It gives you objective data about what happened, rather than relying on secondhand descriptions.
  • When you see repeated failures for the same person, check whether the issue is a configuration problem (affecting everyone) or a person-specific block in Access exceptions.
  • Review the access log periodically for unexpected patterns, such as access attempts at unusual hours or from unfamiliar relations.
  • Keep in mind that the log only records trigger attempts made through Aerolync. Physical access that bypasses the system will not appear here.