txAdmin Server is not responding or panel not loading: causes and fixes

Updated

Verified against FXServer build 35245 (recommended), 37150 (latest) and txAdmin v8.1.1, checked on 7 October 2026. Sources

VerdictCheck other causes first

A Server is not responding restart comes from checks that run on the machine itself, so it points first at a stuck server rather than at the network, and a panel that will not open points first at its port.

FiveShield helps with part of this

FiveShield does not fix a stuck server. For an exposed panel, restrict port 40120 to your own IPs first, which costs nothing; a proxy in front of the panel is a later option.

Two problems share this search. A txAdmin restart with Server is not responding means one of its two monitors went quiet for too long: the server is stuck, or too starved of resources to answer. A panel that will not open is a separate question, about TCP port 40120.

Read the restart line, Restarting server: Server is not responding (HB:<t>|HC:<t>)., to see which monitor gave up, then search the consoles for Loop svMain seems hung! and Server process close detected. Without Restarting server: in front, the same words are only a warning. For the panel, open http://127.0.0.1:40120 on the server itself first.

Consider a DDoS only when something outside the machine says so: a host notice for the same minutes, or an inbound traffic graph that jumps when the failures start.

Messages you may see

  • Server is not responding

    In txAdmin, as the restart reason when the health check or the heartbeat failed for too long

  • HealthChecks failing for the past <t>.

    In the txAdmin console, and in the hover text of the Server badge in the panel sidebar

  • Stopped receiving HeartBeats <t> ago.

    In the txAdmin console, and in the hover text of the Server badge in the panel sidebar

  • Due to a partial hang, this server will restart in 1 minute. Please disconnect now.

    Shown to players in game, before txAdmin restarts a partially hung server

  • Loop svMain seems hung! (last checkin %d seconds ago)

    In the server console, from the FXServer watchdog

What it actually means

txAdmin runs two monitors. The health check sends an HTTP GET for /dynamic.json every 1,000 ms and allows 1,500 ms for the answer; the heartbeat is sent every 3 seconds from inside FXServer by a txAdmin resource named monitor. Each has a 10-second delay threshold and a fatal one: 180 seconds for the health check, 60 for the heartbeat.

Past a fatal threshold, txAdmin restarts the server and logs Restarting server: Server is not responding (HB:<t>|HC:<t>).; HB and HC are how long ago the heartbeat and the health check last succeeded. Once a monitor is 10 seconds late, the same words are only a warning. txAdmin sets the status to offline when both are late and to partial when one is, and prints issue lines after the warning or restart line, such as HealthChecks failing for the past <t>. and Stopped receiving HeartBeats <t> ago. If the heartbeat is fine but the health check has been silent for over 120 seconds, players see Due to a partial hang, this server will restart in 1 minute. Please disconnect now.

The health check targets the address of the endpoint_add_tcp and endpoint_add_udp lines in server.cfg, with 0.0.0.0 or [::] replaced by 127.0.0.1: usually the machine asks itself. It proves FXServer answers locally, not that a player can reach it.

The FXServer watchdog is separate: a loop (svMain, default, svNetwork, svSync) that has not checked in for 45 seconds prints Loop svMain seems hung! (last checkin %d seconds ago), then a svMain watchdog stack: line listing the resources and events it was inside.

Check this first (two minutes)

Three checks, each ending at a cause or a guide.

  1. Does the panel open on the server itself?

    Open http://127.0.0.1:40120 on the txAdmin machine, then check that something listens on the port (Linux first, Windows PowerShell second; use your own port if you changed it).

    ss -ltn 'sport = :40120'
Get-NetTCPConnection -State Listen -LocalPort 40120

  2. Read the last restart line in the txAdmin console

    Find Restarting server: with its reason and (HB:<t>|HC:<t>): HB is the time since the last heartbeat, HC since the last successful health check.

  3. Compare the failure with your host

    Check your host traffic graph and event list for the exact minutes (OVH: Network, then Network Security Dashboard). Only a notice or spike that lines up with the failure points to an attack. An empty record only means the host detected nothing.

Causes, ranked

Editorial order: what owners report most, weighed by how cheap each cause is to check. The attack case comes last because its evidence has to come from outside the machine.

Ranked by what owners report most and how cheap each check is. That is an editorial order, not a statistic: nobody publishes a dataset of FiveM outage causes. Documented means official docs or the FXServer and txAdmin source. Owners report means forum threads and issue trackers. Our inference is our reasoning from documented facts, shown so you can check it.

  1. A script holds the main thread

    Documented

    A handler that never returns (an endless loop, a long blocking call) stops the svMain loop checking in. The heartbeat is a loop in a script inside the server, so it stops too (our reading: the sources do not say which thread runs it), and 60 seconds without one restarts the server.

    How to confirm

    Search the server console for seems hung and watchdog stack:, and the txAdmin console for Detected server thread svMain hung with stack:. A hung svMain passes 45 seconds, and so prints seems hung, before the heartbeat reaches its 60-second limit. Stack entries read <resource>: tick or <resource>: event <name>, innermost first; a stack of only root names no resource.

    What to do

    Stop the named resource with stop <resource> and see whether the restarts end, then update or replace it. Stalls under 45 seconds never reach the watchdog; they show as hitch warnings (see the thread hitch warning guide).

  2. The server process crashed

    Documented

    txAdmin watches the child process. When FXServer exits, txAdmin restarts it at once with Server process close detected and logs FXServer Exited (<exit code>). with the exit code in hex, or a signal name. Exiting within five seconds of starting adds FXServer didn't start. This is not an issue with txAdmin. A port that cannot be bound gives Detected FXServer error: Port <port> is busy!

    How to confirm

    Read the exit code in the txAdmin console. Server process close detected with no seems hung line before it points to a crash, not a hang. A repeating Port <port> is busy! usually means another process, such as an earlier FXServer, holds the port.

    What to do

    Post the exit code and the console lines before it. Test the recommended build, find what changed before the first crash, and free any busy port.

  3. A resource never finishes starting at boot

    Documented

    During boot txAdmin expects resource events at a steady pace, and it does not judge a slow boot before its boot grace period ends. After that, with no resource event 30 seconds into the run, or a gap of over 45 seconds after the last, it restarts with Server boot timed out. One resource over the starting tolerance configured in txAdmin gives Resource "<name>" failed to start within the <t> time limit.

    How to confirm

    The issue lines printed after the warning name the resource: Resource "<name>" has been loading for <t>. or Last resource finished loading <t> ago. If you read Resources started <t> ago but the HTTP endpoint is still unresponsive. instead, the scripts run but the health check never succeeded: read the endpoint_add_* lines in server.cfg.

    What to do

    Fix or remove that resource and check what it waits for, such as a database that does not answer. Raising resourceStartingTolerance only moves the cut-off.

  4. The panel port is closed, changed or not bound

    Documented

    The panel is a separate TCP listener, by default on 40120 on every interface (TXHOST_TXA_PORT and TXHOST_INTERFACE, defaults 40120 and 0.0.0.0). TXHOST_TXA_PORT overrides the deprecated txAdminPort convar and cannot be 30120. If you moved it, or a firewall allows only the game port, it answers on the server and nowhere else: the OVH Game firewall guide recommends Default Deny, which blocks all traffic matching no rule, so game-only rules block 40120 too.

    How to confirm

    Run the step 1 commands on the server. In the local address, 0.0.0.0, * or :: means every interface, 127.0.0.1 the machine only. Open locally but not from outside means a rule in between (system firewall, provider firewall, a Game firewall on Default Deny); nothing listening means txAdmin is not running or uses another port. If no rule explains it, compare with the host record for those minutes (cause 6).

    What to do

    Open TCP 40120 (or your port) only to the IPs you administer from, not to the whole internet. Do not point TXHOST_INTERFACE at a loopback address to hide the panel: its documentation says txAdmin enforces the same variable on FXServer.

  5. The whole machine stalls (VPS lag or a host fault)

    Our inference

    Our reasoning from the documented thresholds: both monitors measure elapsed time, so if the machine freezes or starves FXServer for about a minute, the heartbeat gap passes 60 seconds and txAdmin can restart a server whose scripts did nothing wrong. txAdmin also notices its own stalls: when its once-a-second check is over 10 seconds late, it prints txAdmin was frozen for N seconds for unknown reason (random issue, VPS Lag, DDoS, etc). and skips that one check.

    How to confirm

    Search the txAdmin console for txAdmin was frozen for, and for gaps in other logs on the machine in the same minute. Ask the provider for CPU and host events for that window.

    What to do

    Send the provider the exact timestamps and ask for a host-level explanation. If gaps repeat, change plan or machine; restarting the server does not cure a host that freezes.

  6. A flood on a TCP port, or an attack that stalls the machine

    Our inferenceThe DDoS case

    Our reasoning from what the monitors measure; no source gives figures for any of it. The panel listens on a public TCP port by default, and the health check queries the game port's TCP listener, so either can be targeted alone. A flood of requests on the game port could slow the HTTP answer the health check waits for while scripts keep running (the FiveM server commands page mentions HTTP floods under sv_requestParanoia). Traffic that fills your link, or a host that cuts the address, isolates players and panel while the health check, which stays on the machine, keeps passing: txAdmin shows the server online. A flood that exhausts the machine CPU can stall FXServer and txAdmin long enough to trip the monitors, and the restart then looks exactly like cause 1.

    How to confirm

    Only evidence from outside the machine counts (next section: the host record and an inbound traffic capture). Nothing inside txAdmin tells an attack from a hang.

    What to do

    Restrict 40120 to your own IPs now (cause 4). If the host confirms an attack, do not restart repeatedly, do not announce a new IP and do not try to ban source addresses, which are usually spoofed (OVH says so for its own logs). Keep the evidence and read the host notice guide.

What a DDoS looks like here

txAdmin cannot show an attack; its messages describe the process and one local HTTP request. Only evidence from outside the machine, for the same minutes, can.

What a DDoS looks like here

  • Your host reports an attack or mitigation event on your address for the minutes of the failure.
  • Inbound traffic jumps when the failures start and falls when they end, far above a normal day. The logs may show nothing unusual, or look like a hung script, because an attack that stalls the machine looks like one.
  • The panel is unreachable from outside while http://127.0.0.1:40120 answers on the server, and the host record shows a TCP vector against your address.

Evidence you can collect

  • The host record for the same minutes

    On OVH: Network, then Network Security Dashboard. The scrubbing centre log lists Detection time, End time, Destination IP and Attack vectors and is kept for one year; export the traffic charts promptly (two months in the documentation, two weeks in the OVH marketing FAQ). Source addresses are not shown because they are usually spoofed, so banning them achieves nothing. Other providers differ: ask for a written record.

  • Inbound traffic on the machine

    Capture ten seconds during a failure and ten on a quiet day and compare packets received per second (rxpck/s from sar; Packets Received/sec on Windows, stopped with Ctrl+C). A restart wave is outbound (players downloading again); an attack is inbound.

    sar -n DEV 1 10
Get-Counter -Counter '\Network Interface(*)\Packets Received/sec' -Continuous

What it does not look like

  • A restart right after Loop svMain seems hung! with a stack that names a resource, while the traffic graph stays flat: a script.
  • Server boot timed out, Resource "<name>" failed to start within the <t> time limit or Server process close detected: these describe the process, not the network.

When protection is, and is not, the answer

Nothing in front of a server fixes a hung script: a proxy changes who can reach the machine, not what your scripts do.

Protection is the answer when

  • Your host confirms an attack on your address for those minutes and the traffic graph matches. The next step is the under-attack decision, not txAdmin settings (read the host notice guide).
  • The panel is open to the whole internet, you cannot keep it to your own IPs, and you want it behind something. Restricting 40120 costs nothing and comes first; a proxy in front of the panel comes after it.

Protection is not the answer when

  • The restart reason is Server is not responding and the host shows nothing for those minutes: look at a hung script or a frozen machine, not at an attack.
  • A firewall rule or a changed port blocks the panel: a proxy would meet the same rule and add a hop.
  • Server boot timed out, Loop svMain seems hung! or txAdmin was frozen with a flat traffic graph: fix the resource, or ask your provider.

FiveM anti-DDoS: how FiveShield works

Still stuck? What to post

Paste lines, not descriptions. These let someone else read the cause.

  • The last Restarting server: line from the txAdmin console, with its (HB:<t>|HC:<t>) times.
  • Every seems hung, watchdog stack:, Detected server thread, FXServer Exited ( or Port <port> is busy! line from the minutes before it.
  • Your FXServer build, your txAdmin version, and the result of the step 1 check.
  • If you suspect an attack: a screenshot of the host record for the same minutes, and the sar or Get-Counter output from a failure and from a quiet day.

Frequently asked questions

Why does txAdmin say the server is online when nobody can join?

The health check is an HTTP request from the machine to itself (0.0.0.0 in your endpoint_add_tcp and endpoint_add_udp lines becomes 127.0.0.1), and it never touches the UDP port players use. A firewall rule, a filter at your host, a saturated link or a wrong port forward can leave txAdmin saying online while nobody can reach you. Read the Failed to get info from server guide and compare with the host record.

What is the default txAdmin port, and should it be public?

TCP 40120, set by TXHOST_TXA_PORT, on every interface (TXHOST_INTERFACE defaults to 0.0.0.0). The txAdmin documentation we checked does not say whether it should be public. Players join through the endpoints in server.cfg (30120 by default), not the panel, so our advice is to allow 40120 only from the IPs of your admins.

Can a DDoS make txAdmin restart my server?

Not through the network alone. Traffic that only fills the network path cannot make the health check fail, since it never leaves the machine. A flood that reaches the game port's HTTP side, which the check queries, or one that stalls the machine long enough, could, and the txAdmin freeze message names DDoS among its possible reasons. Either way the restart looks like an ordinary hang, and only evidence from outside the machine tells them apart. No source we checked says how often this happens.

Verified against, and sources

Verified against FXServer build 35245 (recommended), 37150 (latest) and txAdmin v8.1.1, checked on 7 October 2026.

Sources from companies that compete with FiveShield are named, with their domain, but not linked.

Server behaviour changes between builds. If your build prints something different, the build numbers above tell you what this page was checked against.