What the last 1000 lines of Asterisk CLI output tell you

When your dialer starts behaving strangely — calls dropping, trunks not picking up, agents hearing silence — the Asterisk Debug Page is often the fastest place to look. It pulls together the last 1000 lines of Asterisk CLI output, the current state of your SIP peer table, and the SIP and IAX registration status, all on one screen. This post walks through what each section means and how to read the output without getting lost.

How to enable the debug page

The page is off by default. To turn it on, open your server record in the Administration section and enable the Asterisk Debug setting. Once enabled, VICIdial begins capturing CLI output in the background. The page then becomes available under the Reports section and shows a live snapshot each time you load it.

Because the buffer holds only the last 1000 lines, a very busy or very noisy server can rotate through them quickly. If you are chasing an intermittent problem, load the page shortly after the symptom appears rather than waiting.

Reading the SIP peers and registry section

The first block on the page lists every SIP (Session Initiation Protocol) peer Asterisk knows about and their current state. Each row shows the peer name, the host and port Asterisk is talking to, whether the peer is reachable, and the last measured round-trip time in milliseconds. Peers marked OK with a low round-trip figure are healthy. Peers showing UNREACHABLE or LAGGED are where your attention should go.

Below the peer list, the registry section shows whether Asterisk has successfully registered with your upstream Carrier or SIP provider. Each entry shows the registration target, the username used, whether the registration is active, and when it expires. If a registration shows as Failed or is absent entirely, outbound calls through that trunk will not complete.

What the CLI output stream shows

The bulk of the page is the raw CLI buffer. It reads like a log: each line is timestamped and prefixed with a severity and module name. The most useful prefixes to scan for are:

• WARNING — something worked but not cleanly. Common examples: codec negotiation fallback, a peer that responded slowly, a retransmit that eventually succeeded.
• ERROR — something failed. Registration rejections, authentication failures, and unreachable hosts all appear here. These usually need action.
• NOTICE — informational events. Peer registered, peer unregistered, a channel came up or hung up. These fill most of the buffer on a busy system.

When the buffer is crowded with NOTICE lines about Channel creation and teardown, scroll past them and look for clusters of WARNING or ERROR entries. A cluster that starts at a specific time tells you when something went wrong — match that timestamp to a call-drop complaint or a report of agents losing audio.

Common patterns and what they mean

flowchart TD
  A["Load debug page"] --> B{"Peer status OK?"}
  B -->|No| C["Check registry block"]
  C --> D{"Registration active?"}
  D -->|No| E["Carrier credentials or firewall issue"]
  D -->|Yes| F["Peer network path problem"]
  B -->|Yes| G["Scan CLI buffer for WARNING/ERROR"]
  G --> H{"Errors found?"}
  H -->|Yes| I["Match timestamp to symptom"]
  H -->|No| J["System clean — check agent side"]

A registration failure usually appears as a 403 Forbidden or 401 Unauthorized in the CLI alongside a registry entry marked Failed. This is almost always a credentials mismatch or a firewall blocking the registration packet. A peer marked UNREACHABLE with no errors in the CLI often means the far-end host is offline or the network path between your box and the carrier dropped.

Codec negotiation failures appear as WARNING messages mentioning "no compatible codecs" or a similar phrase. These happen when your trunk is configured to offer G.729 codec or G.711 codec in a combination the carrier does not accept. The call attempt is visible in the buffer — it appears, gets a BYE response almost immediately, and the channel tears down.

Using this page alongside other health checks

The debug page answers "what is Asterisk saying right now" but it does not show you server load, channel counts, or longer-term trends. For those, pair it with the server health and capacity guide. If you have already confirmed the Asterisk side looks clean but agents are still reporting problems, the next place to look is the SIP peer quality over time — covered in how to check SIP peers and registry in VICIdial.

Want a VICIdial box where the debug page is available from day one and the server is sized correctly for your call volume? See VICIfast plans and pricing — provisioning takes under 40 seconds.