Documentation

Object model

WAFDOG is project scoped. Projects own applications, applications own checks, and checks produce results.

Project
  -> Application (hostname)
     -> Verification (secret, DNS, or path)
     -> Checks (DNS, SSL, WAF, Uptime, Header, Simple HTTP)
         -> Results and history
  -> Team members and roles
  -> Credits and spend log

Project scope

The active project in the header controls what you see and edit. Switching projects changes lists, dashboards, and API context.

• Applications are isolated per project.
• Checks always belong to a single application.
• Credits and spend are tracked per project.

Verification

Verification proves that you own the hostname before checks are allowed to run.

• Secret verification uses a short code that must be returned by the host.
• DNS verification uses a TXT record with a secret value.
• Well-known verification uses a file path on the host.

Only verified hostnames can be checked, which prevents abuse and false positives.

Check lifecycle

1. A check is created with a schedule and configuration.
2. The checker runs the check on schedule.
3. Results are stored and summarized.
4. Alerts are triggered if thresholds are crossed.

Results appear in dashboards and history views. Manual rechecks create immediate jobs.

Tools and quick scans

Guestcheck and Quickcheck sound similar but serve different jobs. Use the tool comparison when deciding between public scans, Member Quickcheck, and scheduled checks.

Status model

Roles and permissions

Roles control which actions users can perform within a project. Available roles depend on configuration and plan.

• Owners can manage billing, team, and project settings.
• Editors can manage applications and checks.
• Viewers can read dashboards and reports.

If a user lacks a permission, actions are hidden or blocked.

Glossary