Troubleshooting

This usually means Slack can't reach your bot's request URL. Check the following:

• Your bot process is running and listening on the configured port.
• The Request URL in your Slack app's Slash Commands settings matches the public URL of your deployment (e.g. https://yourdomain.com/slack/events).
• Your server's TLS certificate is valid — Slack requires HTTPS with a trusted certificate.
• No firewall or reverse proxy is blocking inbound requests from Slack's IP ranges.

You can verify reachability by running:

curl -X POST https://yourdomain.com/slack/events

You should receive a 400 or 401 response (not a connection error).

Morgenruf must be invited to the channel before slash commands can be used there. In Slack, run:

/invite @Morgenruf

If you're self-hosting, also verify that your Slack app manifest includes the commands scope and the correct slash command definition.

The redirect URI registered in your Slack app must exactly match the one used at runtime. In your Slack app settings under OAuth & Permissions → Redirect URLs, ensure the entry matches your APP_URL environment variable, including the path:

https://yourdomain.com/slack/oauth_redirect

Trailing slashes and HTTP vs HTTPS differences will cause a mismatch.

When a workspace reinstalls the app, Slack issues a new token and invalidates the old one. Morgenruf stores the latest token automatically during the OAuth callback. If you see invalid_auth errors:

1. Remove Morgenruf from your workspace in Slack → Apps → Remove App.
2. Reinstall via the "Add to Slack" button on morgenruf.dev (or your self-hosted install URL).

For self-hosted deployments, also verify the SLACK_CLIENT_ID and SLACK_CLIENT_SECRET environment variables match the credentials in your Slack app settings.

Check that your DATABASE_URL environment variable is set and points to a reachable PostgreSQL instance:

postgresql://user:password@host:5432/morgenruf

Common causes:

• The database container hasn't finished starting up — add a depends_on health check in your docker-compose.yml.
• The hostname is incorrect — when using Docker Compose, use the service name (e.g. db), not localhost.
• The database user lacks the CREATE privilege needed for migrations.

Morgenruf runs database migrations automatically at startup. If migrations fail:

• Ensure the database exists before the app starts (create it with createdb morgenruf or via your cloud provider).
• Check the application logs for the specific SQL error — it usually points to a permission or version incompatibility.
• PostgreSQL 13 or newer is required.

To run migrations manually:

docker run --rm -e DATABASE_URL=... ghcr.io/morgenruf/morgenruf:latest migrate

The most common cause is a timezone misconfiguration. Verify:

• The workspace timezone in Dashboard → Settings is set to the correct IANA timezone (e.g. America/New_York, not EST).
• Individual members haven't set a personal timezone override that conflicts with expectations — they can check with the DM command: timezone.
• The server's system clock is accurate (run date in the container to verify).

If no DMs were sent at all:

• Check that the standup is active in the dashboard — it may have been paused.
• Confirm the scheduled day is enabled (e.g. if today is Monday, verify Monday is checked under Active Days).
• If self-hosting, check that only one instance of the bot is running — multiple replicas can cause the scheduler to skip jobs. Use a single scheduler replica or a distributed lock (see the Self Hosting docs).
• Review application logs around the scheduled time for scheduler errors.

The reaction needs the reactions:write scope, and workspaces that installed Morgenruf before it existed have not granted it. The scope is optional, which is why the posts still go out.

• A workspace admin clicks Re-authorise Slack on the Celebrations page. Posts after that get the reaction.
• If you're self-hosting, add reactions:write to your Slack app's bot scopes first (see Upgrading to member profiles and Celebrations), then re-authorise.

Check the following:

• Celebrations is turned on, and a channel and a timezone are saved.
• @Morgenruf has been invited to the celebrations channel.
• The person has the date in their profile and has not ticked Don't celebrate me publicly.
• For an anniversary, the start date is at least a year ago.
• The day was not a day off. A celebration on a weekend or a listed holiday is posted on the last working day before it, so look there. The Coming up list on the Celebrations page shows which day each one is posted.

Open the browser developer console (F12 → Console) and look for errors. Common causes:

• Content Security Policy (CSP) error: If you're running behind a reverse proxy, ensure it isn't injecting a CSP header that blocks the app's scripts.
• API 401 errors: Your session has expired. Log out and log back in via the Sign in with Slack button.
• API 500 errors: A backend error — check server logs for the root cause.

Only workspace admins and members added in Dashboard → Members can access the dashboard. If you're an admin and still see this error:

1. Sign out and sign back in with Slack to refresh your session.
2. Confirm you're signing in with the same Slack account that installed the app.
3. If self-hosting, verify the SESSION_SECRET environment variable is set and hasn't changed since installation.

Inspect the container logs to find the root cause:

# Docker
docker logs morgenruf --tail 50

# Kubernetes
kubectl logs deployment/morgenruf --tail 50

Common causes:

• A required environment variable is missing — see Environment Variables for the full list.
• The database is unreachable at startup (see Database Connection Issues above).
• Port conflicts — ensure nothing else is bound to the same port on the host.

Check the pod events for scheduling or image-pull errors:

kubectl describe pod -l app.kubernetes.io/name=morgenruf

Common causes:

• ImagePullBackOff: The image tag in your values.yaml doesn't exist or the registry is unreachable. Use ghcr.io/morgenruf/morgenruf:latest or a pinned version tag.
• Pending / Insufficient resources: Your cluster doesn't have enough CPU or memory. Lower the resource requests in values.yaml or add nodes.
• Secret not found: If you're using Kubernetes Secrets for environment variables, verify the secret exists in the same namespace as the deployment.

See the Kubernetes / Helm docs for a full deployment walkthrough.

A 502 from the ingress means it can reach the service but not the pod. Verify:

• The pod is Running and its readiness probe is passing: kubectl get pods.
• The Service targetPort matches the port the app listens on (default 3000).
• If using TLS termination at the ingress, the backend service should target HTTP, not HTTPS.

Check ingress controller logs for more detail:

kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail 50