Under attack: what to do
Mitigation is already running on a provisioned service. Your job during an event is to confirm the path, avoid making it worse, and give Templass a usable report if humans need to join.
Under Attack actions
Do these in order. Do not skip the first two to "try a new IP" on your origin.
- Open Panel. Sign in at panel.templass.com.
- Read Attacks. Confirm whether Templass is recording the event. Guide: Attacks view.
- Check Dashboard. Is clean traffic still flowing, or is the origin silent?
- Do not leak the origin. Do not move DNS to the real server, post the origin IP in public Discord, or announce the prefix on a backup ISP "just for now."
- Call humans if the service is down. Use the contacts below with the facts listed in "What to send."
:::info Under Attack Stay on Templass. Join Discord, keep Panel open, and write [email protected] if the channel is quiet. For capacity or commercial changes mid-event, use [email protected]. :::
Panel first
| Screen | Why you open it |
|---|---|
| Attacks | See whether FR5 is handling a recorded event |
| Dashboard | Clean rate vs a dead origin |
| Firewall | Tighten only if you know the bad pattern |
| Rate limiting | Cap a noisy protocol you intend to keep |
Firewall and rate-limit changes can take time to provision. Do not spam toggles every few seconds. If you are unsure, ask in Discord before you submit a rule that blocks your own users.
Discord and email
- Discord invite: fastest for "it is happening now."
- [email protected]: written trail, attachments, follow-up.
- [email protected]: plan upgrade, Custom capacity, cross-connect urgency.
Platform notes: status.templass.com. More in Status and support.
What to send
Keep it factual. No customer names of other people, no fake packet captures.
- Panel login email
- Protected IP or prefix (the one Templass issued)
- Approximate start time (UTC)
- Symptom: down, lag, only one port, only one region
- Whether Attacks shows an event
- Recent firewall or rate-limit changes you made
- Confirmation that DNS still points at Templass
What not to do
- Do not rebuild GRE against a guessed Templass IP
- Do not null-route
<PROTECTED_PREFIX>on your origin unless Templass asked you to - Do not open the origin to the world "to test"
- Do not rotate to a new VPS and publish it as the game server mid-attack
After the event
Leave Attacks open long enough to see the end. If something stayed broken after Attacks went quiet, the remaining issue is usually local (process down, disk, application). Templass cannot restart your host.
If you want a permanent policy change (new port, tighter firewall), file it after the event so provisioning is not mixed with emergency chat.