Not every deployment event deserves the same level of attention. A successful push to staging probably does not need to ping your entire team, but a failed production deployment absolutely does. That is why DeployHQ gives you granular control over exactly when your third-party notification integrations fire.
Instead of an all-or-nothing approach, you can independently toggle notifications for three distinct deployment events — giving you the flexibility to match your alert strategy to each environment and team workflow.
The Three Notification Triggers
DeployHQ lets you control notifications at three points in the deployment lifecycle:
flowchart LR
A["Deployment Starts"] -->|Build & Transfer| B["Deployment In Progress"]
B -->|Success| C["Deployment Succeeded"]
B -->|Failure| D["Deployment Failed"]
style A fill:#3b82f6,color:#fff
style C fill:#22c55e,color:#fff
style D fill:#ef4444,color:#fff
| Trigger | When It Fires | Typical Use Case |
|---|---|---|
| On start | As soon as the deployment begins | Heads-up that a release is underway |
| On success | After a deployment completes without errors | Confirmation the release is live |
| On failure | When a deployment encounters an error | Immediate alert for investigation |
Each trigger is an independent toggle — enable any combination that fits your workflow.
How to Configure Notification Triggers
Step 1: Open Your Project Integrations
Navigate to your project in DeployHQ, then click Integrations in the left sidebar.
Step 2: Add or Edit an Integration
Click New Integration to add a notification channel, or edit an existing one. DeployHQ supports several channels:
- Discord
- Microsoft Teams
- Slack
- Browser push notifications
- Bugsnag, Honeybadger & Sentry
- Rollbar
Step 3: Set Your Triggers
In the integration configuration screen, you will see three toggles controlling when notifications are sent:
Enable or disable each trigger independently, then click Save (or Create Integration for new integrations).
Step 4: Choose Which Servers to Notify On
You can also scope notifications to specific servers. For example, send failure alerts for all servers but only send success notifications for production.
Standardizing Triggers With Project Templates
If you manage multiple projects — common for agencies and teams with many sites — you do not want to configure triggers manually every time.
DeployHQ's project templates let you define notification trigger settings once and apply them to all new projects in your account. Set up a template with your preferred notification strategy, and every project created from that template inherits the same configuration.
flowchart TD
T["Project Template"] --> P1["Project A"]
T --> P2["Project B"]
T --> P3["Project C"]
P1 --> N1["Start + Failure alerts"]
P2 --> N2["Start + Failure alerts"]
P3 --> N3["Start + Failure alerts"]
This is especially useful when you want a consistent notification policy across your entire organization — for example, always alerting on failures but only notifying on start for production servers.
Common Notification Strategies
Here are some patterns that work well depending on your environment and team size:
Production: Full Visibility
Enable all three triggers. Everyone should know when a production deployment starts, succeeds, or fails.
- On start: Yes — team knows a release is in progress
- On success: Yes — confirmation the release is live
- On failure: Yes — immediate incident awareness
Staging: Failures Only
Staging deployments happen frequently. Avoid alert fatigue by only notifying on failures.
- On start: No
- On success: No
- On failure: Yes — something needs attention
CI/CD Pipelines: Start + Failure
For automated deployments triggered by CI/CD pipelines, you want to know when a deployment kicks off and if it fails — but successful auto-deploys can be silent.
- On start: Yes — visibility into what is being deployed
- On success: No — reduces noise
- On failure: Yes — needs human attention
Multi-Channel Strategy
You can set different triggers on different integrations. For example:
- Slack → All three triggers (team channel)
- Email → Failures only (on-call engineer)
- Discord → Start + success (stakeholder visibility)
Combining With DeployHQ's Monitoring Tools
Notification triggers work alongside DeployHQ's broader deployment monitoring capabilities. For deeper insight into what happened during a deployment, you can also use:
- Deployment logs: Detailed output from each deployment step
- AI-powered log analysis: Automatic identification of errors and warnings
- AI deployment overviews: Natural language summaries of what changed
- Troubleshooting tools: Step-by-step guidance when things go wrong
FAQ
Can I set different triggers per server?
Not directly per-server on a single integration, but you can achieve this by creating multiple integrations for the same channel with different server scopes. For example, one Slack integration scoped to production with all triggers enabled, and another scoped to staging with failures only.
Do these trigger settings apply to email notifications?
Yes. The trigger toggles apply to all third-party integrations, including email, Slack, Discord, Microsoft Teams, and webhook-based services like Bugsnag and Sentry.
Can I change triggers on an existing integration?
Yes. Go to Integrations in your project, click on the existing integration, and update the toggles. Changes take effect immediately on the next deployment.
What happens if I disable all three triggers?
The integration remains configured but will not send any notifications. This can be useful if you want to temporarily silence alerts without removing the integration entirely.
Are triggers inherited when I use the DeployHQ API?
Yes. Notifications fire based on the configured triggers regardless of whether the deployment was started manually, via automatic hooks, or through the DeployHQ API.
Take control of your deployment alerts and reduce noise for your team. Sign up for DeployHQ or explore the full list of supported integrations in our documentation. For questions, reach out to support@deployhq.com or find us on X @deployhq.