Menu
Feature · Features
UDP monitoring (planned)
Planned capability — not yet available to create. UDP-based service checks are on the FTStatus roadmap for cases with a clear request, response, and timeout rule that can be validated safely from outside the network.
- HTTP · DNS · TCP
- live checks
- 1 min
- Team cadence
- Real
- uptime history
- Public
- status page
Use UDP checks only for services with a reliable external response pattern.
Pair UDP results with DNS, TCP, or HTTP checks when customer impact depends on more than one signal.
Keep ports, hostnames, and provider-specific details out of public status copy.
Monitor
What it checks
Planned — not yet available to create. When shipped, UDP monitoring will be useful for supported services where FTStatus can send a defined probe and evaluate a bounded response without exposing internal service details.
Response time · 24h
182 msAlerting
How alerts work
Because UDP is connectionless, alert rules should use conservative timeout, retry, and location confirmation settings before changing customer-facing status.
Status pages
What customers see
Public pages should describe the affected customer-facing service, not raw ports, probe payloads, or provider configuration.
Looks right either way
Light or dark, your status page stays on-brand.
Match what your customers expect with a clean light or dark public page — same components, same clarity.
Last 90 days · 99.98% uptime
Safe for public status pages
- Website and application availability
- API health endpoint status
- DNS and SSL issues affecting customer access
- Maintenance windows and incident timelines
- High-level region coverage
Internal operations only
- SSH, admin panels, databases, queues, and backups
- Server names, origin IPs, provider IDs, and ports
- Firewall rules, file paths, and secret-related config
- Primary or backup probe node details
- Customer-specific private control panels
Setup workflow
From first check to customer-ready status.
Define the UDP service, expected response, timeout, and safe public component name.
Confirm the check from more than one logical monitoring location.
Attach confirmed failures to alert routes and status-page impact only when customer-facing service is affected.
Decide with confidence
Where udp monitoring (planned) earns its place
A useful monitor is tied to a customer journey, an owner, and a response rule. The goal is not more checks; it is earlier detection with less noise.
Use this when
- Use UDP checks only for services with a reliable external response pattern.
- Pair UDP results with DNS, TCP, or HTTP checks when customer impact depends on more than one signal.
- Keep ports, hostnames, and provider-specific details out of public status copy.
Set the boundary
- This page includes a capability that is clearly marked as planned. Use the live or operator-assisted path described here until the self-serve workflow is released.
- Keep server names, credentials, provider identifiers, and internal diagnosis out of public status updates.
- Pair uptime evidence with application logs or tracing when the question is why a service failed, not whether customers can reach it.
Product evidence
A real reliability workflow, not a promise deck.
FTStatus earns trust with a product you can inspect and a setup you can test before it becomes part of a customer-critical service.
View live demoA live public experience
Open a real FTStatus status page and inspect the same component, incident, maintenance, and subscription flow your customers will use.
A testable operating loop
Create a monitor, run the check, verify the alert path, publish customer-safe impact, and retain the incident timeline.
Honest capability boundaries
Live, operator-assisted, managed-only, and planned workflows are labelled so buyers can scope the service without hidden assumptions.
Before you choose
Questions buyers ask before setup.
Clear scope now prevents surprise costs, noisy alerts, and public status pages that expose the wrong detail later.
What does udp monitoring (planned) cover?+
Planned capability — not yet available to create. UDP-based service checks are on the FTStatus roadmap for cases with a clear request, response, and timeout rule that can be validated safely from outside the network.
What should I configure first?+
Use UDP checks only for services with a reliable external response pattern. Then test the failure and recovery path before attaching the monitor to customer notifications.
Will technical details appear on the public status page?+
No. Public components describe the affected customer-facing service. Infrastructure details and investigation notes remain in the internal workflow.
Can Faciotech configure and maintain this for us?+
Yes. Managed monitoring can include scope design, monitor setup, alert tuning, status-page maintenance, and incident coordination when included in the agreed service.
Related pages
Continue building the monitoring workflow.
Set up monitoring your customers can trust.
Start free with the checks that matter — sites, APIs, DNS, and hosted services — then add status pages and alert routing as you grow. No credit card, and local Faciotech support when you need it.