> ## Documentation Index
> Fetch the complete documentation index at: https://docs.certgov.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Services

> Group hostnames and certificate configurations under named services with owners.

A **Service** is a named grouping of hostnames that belong to the same application or workload. Services connect certificates to the business context they protect — who owns them, which hostnames they cover, and whether coverage is complete.

## Why services exist

Without services, a certificate is just a domain name and an expiry date. With services you can answer:

* Which team is responsible when this cert expires?
* Does the payments API have valid certificates covering all its endpoints?
* Who gets notified when auth service certs are expiring?

## Creating a service

Go to **Services → Add Service**, or create one inline during the certificate wizard (step 1: select a service → "Create new service").

| Field           | Description                                                     |
| --------------- | --------------------------------------------------------------- |
| **Name**        | Human-readable name (e.g. "Payments API")                       |
| **Type**        | `web`, `api`, `internal`, `infrastructure`, or `other`          |
| **Environment** | `production`, `staging`, `development`, etc.                    |
| **Owners**      | One or more email addresses; receives cert expiry notifications |

## Hostnames and cert groups

After creating a service, add hostnames on the service detail page. Hostnames are organized into **cert groups** — each group produces one certificate covering all hostnames in that group.

**Example:** A service with three hostnames in two cert groups:

| Hostname                   | Cert Group |
| -------------------------- | ---------- |
| `api.example.com`          | 1          |
| `api-internal.example.com` | 1          |
| `api-mgmt.example.com`     | 2          |

This issues two certificates: one SAN cert for both `api.*` names, one for `api-mgmt`.

Use multiple cert groups when:

* Some hostnames need a separate cert (different CA, different validity, or separate ACME account)
* Kubernetes workloads in different namespaces need individual certs

## Service coverage

The **Service Coverage** report (Reports → Service Coverage) shows each service with:

| Status       | Meaning                                               |
| ------------ | ----------------------------------------------------- |
| **Full**     | Every cert group has a valid, non-expired certificate |
| **Partial**  | Some cert groups are covered, others are not          |
| **None**     | Service has hostnames but no active certificates      |
| **No certs** | Service has no hostnames configured                   |

The dashboard Active Certs KPI counts distinct cert groups, not raw cert records.

## Cert expiry reports

**Reports → Service Cert Expiry** lists all service-associated certs expiring within a configurable window, grouped by service with owner emails. This is distinct from the general cert expiry report which covers all certs regardless of service association.

Both the Service Coverage and Service Cert Expiry reports are available as scheduled email subscriptions — go to **Profile → Report Subscriptions**.

## Owner notifications

When a `cert_expiring` alert rule fires, CertForge sends each service's owners a targeted email listing only the certs belonging to their service. Owners must opt in via **Profile → Alert Subscriptions → Service cert expiry (notify me as service owner)**.

See [Alerts](/concepts/alerts) for full alert configuration.