Key Concepts

This page defines the key terms and concepts you will encounter throughout Seenty. Understanding these will help you navigate the platform and make the most of its features.

Organization

An organization is a multi-tenant workspace. All resources in Seenty -- domains, monitors, incidents, integrations, and team members -- belong to an organization. Each organization has its own billing subscription and data isolation.

You can be a member of multiple organizations and switch between them from the sidebar.

Domains

A domain is a registered internet domain (e.g., example.com) that you want Seenty to monitor and scan for security issues. After adding a domain, you must verify ownership by adding a DNS TXT record. Verification unlocks the full scanning pipeline:

• DNS record scanning -- Available immediately, even without verification
• Subdomain discovery -- Automatic passive discovery via certificate transparency logs (Starter+)
• Technology detection -- Identifies web servers, frameworks, CDNs, and CMS platforms (Pro+)
• CVE vulnerability scanning -- Checks detected technologies against known vulnerability databases (Ultra+)
• Nightly scans -- Automatic scans at 3:00 AM UTC for verified domains (Starter+)

Service Monitors

A service monitor is an uptime check that Seenty runs at regular intervals from multiple global regions. There are three types:

• HTTP/HTTPS -- Sends an HTTP request and checks the response status code, response time, and optionally the response body for keywords.
• Ping (ICMP) -- Sends an ICMP ping to verify host reachability and measure latency.
• TCP (Port) -- Attempts a TCP connection to a specific port to verify the service is accepting connections.

When a monitor detects a failure, it triggers notifications and (on Pro+ plans) creates an incident.

Incidents

An incident represents a detected problem that requires attention. Incidents are created automatically when a monitor fails, and they track the full lifecycle of the issue:

• Triggered -- The incident is detected and alerts are sent.
• Acknowledged -- A team member has seen the alert and is investigating.
• Resolved -- The issue has been fixed and the service is healthy again.

Each incident has a timeline that records every event: when alerts were sent, who acknowledged, what notes were added, and when it was resolved.

Findings

A finding is a security issue discovered by one of Seenty's scanners. Findings are categorized into three types:

• Misconfigurations -- Incorrect or insecure configurations in your DNS, cloud accounts, or infrastructure. Examples: dangling DNS records, publicly accessible S3 buckets, security groups with unrestricted ingress.
• Vulnerabilities -- Known security flaws (CVEs) in the technologies running on your domains or dependencies in your repositories.
• Secrets -- Exposed credentials, API keys, tokens, or passwords found in your code repositories.

Each finding has a severity (Critical, High, Medium, Low, Info) and a status (Open, Acknowledged, Resolved, False Positive).

Escalation Policies

An escalation policy defines a multi-step alert chain for incidents. If the on-call person does not acknowledge the incident within a configured delay, the alert escalates to the next step.

For example:

1. Step 1 (0 min delay) -- Alert the current on-call engineer via email and SMS.
2. Step 2 (10 min delay) -- If not acknowledged, alert the team lead via Slack.
3. Step 3 (30 min delay) -- If still not acknowledged, alert the engineering manager via phone call.

Escalation policies can also be configured to repeat the entire chain if the incident remains unacknowledged.

On-Call Schedules

An on-call schedule defines who is responsible for responding to incidents at any given time. Seenty supports:

• Daily rotation -- The on-call person changes every day.
• Weekly rotation -- The on-call person changes every week.
• Custom rotation -- Define your own rotation period.

Schedules can have overrides -- temporary changes for vacations, sick days, or planned absences. When an incident is triggered, Seenty resolves the current on-call person using the schedule, checking overrides first.

Status Pages

A status page is a public-facing web page that communicates the health of your services to your users. Status pages show:

• Components -- Individual services or systems, each with a current status (Operational, Degraded, Partial Outage, Major Outage, Under Maintenance).
• Component Groups -- Logical groups of related components.
• Incidents -- Public incident updates with real-time status changes.
• Uptime History -- Historical uptime data for each component.

Users can subscribe to status pages via email, Slack, Discord, Microsoft Teams, Webhooks, or RSS/Atom feeds to receive notifications about status changes.

Notification Channels

A notification channel is a configured destination for alerts. Seenty supports:

Channels are configured at the organization level and can be assigned to monitors, escalation policies, or status page subscribers.

Personal Notification Rules

Personal notification rules let individual team members define their own alert sequence when they are on-call. For example, a user might configure:

1. Email immediately
2. SMS after 5 minutes if not acknowledged
3. Push notification after 10 minutes if still not acknowledged

These rules are personal -- each team member sets their own preferences. They work in addition to the default email notification, which is always sent.

Roles

Every organization member has a role that determines what they can do:

Plans

Seenty offers five plans with increasing capabilities:

See Billing for full details on plan limits and features.