Administration
Configure notifications, authentication, data retention, and system settings
Administration
This section covers the administrative configuration of OpsKnight, including notification providers, authentication, data retention, custom fields, and audit logging. These settings are typically configured once during setup and reviewed periodically.
Who Should Read This
- System Administrators — Setting up OpsKnight for your organization
- DevOps/Platform Engineers — Configuring notification channels
- Security Teams — Setting up SSO, reviewing audit logs
- Operations Managers — Understanding data retention and compliance
Administration Topics
| Topic | Description | Why It Matters |
|---|---|---|
| Notifications | Configure Email, SMS, Push, WhatsApp, Slack | Ensure alerts reach responders |
| Authentication | Local auth, SSO/OIDC, user management | Secure access control |
| Custom Fields | Add metadata fields to incidents | Track additional information |
| Data Retention | Configure cleanup policies | Manage storage and compliance |
| Audit Logs | Track security-relevant events | Compliance and troubleshooting |
Quick Setup Checklist
When setting up OpsKnight for your organization, complete these administrative tasks:
1. Configure Notification Channels
Without notifications, OpsKnight can't alert responders. Set up at least one channel:
| Priority | Channel | Setup Guide |
|---|---|---|
| Essential | SMTP/SendGrid/Resend setup | |
| Recommended | Slack | Slack OAuth integration |
| For Critical Alerts | SMS | Twilio/AWS SNS setup |
| For Mobile | Push | FCM/OneSignal setup |
2. Set Up Authentication
Choose your authentication strategy:
| Option | Best For | Setup |
|---|---|---|
| Local Auth | Small teams, quick start | Default, no config needed |
| Google SSO | Google Workspace orgs | OIDC setup |
| Microsoft Entra | Microsoft 365 orgs | OIDC setup |
| Okta/Auth0 | Enterprise with IdP | OIDC setup |
3. Create Teams and Invite Users
- Create teams to organize responders
- Invite users via email
- Assign roles (User, Responder, Admin)
- Add users to teams with appropriate roles
4. Configure Data Retention (Optional)
Set retention policies based on your compliance needs:
- Incidents: 2 years (default)
- Alerts: 1 year (default)
- Logs: 90 days (default)
5. Review Audit Logs
Understand what's being tracked:
- Login attempts
- User management changes
- Configuration changes
- Data access events
Accessing Admin Settings
Via UI
- Click Settings in the sidebar
- Sections available depend on your role:
- Users: Everyone can access their profile
- Teams: Team admins can manage their teams
- System Settings: Admin role required
Via API
Admin endpoints require admin API keys:
# List users (admin only)
curl -H "Authorization: Bearer sk_admin_xxx" \
https://opsknight.yourco.com/api/users
Admin Roles and Permissions
| Role | Capabilities |
|---|---|
| User | View incidents, acknowledge, basic profile settings |
| Responder | All User permissions + on-call + incident management |
| Admin | All permissions + system settings + user management |
What Admins Can Do
- Configure notification providers (Email, SMS, Push)
- Set up SSO/OIDC integration
- Manage all users (invite, disable, change roles)
- Configure custom fields
- Set data retention policies
- View and export audit logs
- Configure system settings (App URL, encryption)
System Health Monitoring
Health Check Endpoint
curl https://opsknight.yourco.com/api/health
Response:
{
"status": "ok",
"database": "connected",
"version": "1.0.0"
}
What to Monitor
| Component | What to Check |
|---|---|
| Database | Connection status, query performance |
| Job Queue | Pending jobs, failed jobs |
| Notifications | Delivery success rate |
| Integrations | Webhook success rate |
Security Considerations
Sensitive Data
OpsKnight stores sensitive configuration that should be protected:
| Data | Storage | Protection |
|---|---|---|
| API keys | Database | Encrypted at rest |
| OAuth tokens | Database | Encrypted at rest |
| SMTP credentials | Database | Encrypted at rest |
| User passwords | Database | Bcrypt hashed |
Access Control
- Use SSO when possible for centralized identity management
- Enable MFA at your identity provider
- Review audit logs regularly
- Rotate API keys periodically
- Use least privilege — only grant Admin role when necessary
Data Privacy
- Configure data retention to meet compliance requirements
- Incidents and alerts are deleted after retention period
- Audit logs have separate retention (typically longer)
- Consider GDPR/CCPA requirements for user data
Troubleshooting Common Issues
Notifications Not Sending
- Check provider configuration in Settings → Notifications
- Verify credentials are correct
- Test with "Send Test" button
- Check system logs for errors
- Verify user has notifications enabled
Users Can't Log In
- Check user status (ACTIVE, DISABLED, INVITED)
- For SSO: Verify OIDC configuration
- For local auth: Check password requirements
- Review audit logs for failed login attempts
- Check rate limiting (lockout after failures)
Data Not Appearing
- Check data retention settings
- Verify database connectivity
- Check if data was deleted by retention policy
- Review system logs for errors
Related Topics
- Security — Encryption, SSO, access control
- Deployment — Production setup
- Architecture — System internals
Last updated for v1
Edit this page on GitHub