Your Account
Manage your profile, password, login methods, account merges, and understand how your identity works across organizations.
Your Account
Account Model
One person, one account — even when you sign in several different ways.
UptimeHunt lets a single account carry multiple login methods: a password, Google or GitHub social sign-in, and one or more organization SSO identities. Every login method is an independent way to prove you are who you say you are; they all sign you into the same account.
Login methods are managed from Settings → Login & Email. The Security tab's Change Password form is a shortcut for updating an existing password.
Why two accounts can exist for one email
For safety, UptimeHunt never silently links accounts by email alone. Signing up with a password, then later "Continue with Google" using the same address, can leave you with two separate accounts that happen to share an email — each in its own identity realm. That is intentional (it blocks account-takeover by email claim), and the account-merge flow below is how you safely combine them once you have proven you own both.
Profile Information
Accessing Account Settings
- Log in to your UptimeHunt account.
- Click the user menu in the navigation bar (displays your Gravatar or initials).
- Select "Settings" from the dropdown menu.
Updating Your Profile
The Profile tab displays your name, email address, and Gravatar. To update:
- Navigate to Settings → Profile tab.
- Modify First Name, Last Name, or Email Address as needed.
- Click "Save Changes".
Email Address Changes
Changing your email address updates your login credentials. Use the new email address for subsequent logins. See Email Management for managing multiple addresses.
Profile Picture (Gravatar)
UptimeHunt uses Gravatar for profile pictures — create or update a Gravatar account using your UptimeHunt email address, and the picture appears automatically.
Password Management
Changing Your Password
If your account already has a password, update it from the Security tab:
- Navigate to Settings → Security tab.
- Enter your Current Password, New Password, and confirmation.
- Click "Change Password".
Password Security
Changing your password does not invalidate existing sessions. Log out from all devices after changing your password for maximum security.
Setting a Password for the First Time
If your account was created via Google, GitHub, or an organization SSO sign-in and has no password yet, the Change Password form requires a current password — use the Login & Email tab or the API to add a password as a new login method:
curl -X POST https://app.uptimehunt.io/api/v1/auth/account/login-methods \
-H "Authorization: Bearer {access_token}" \
-H "Content-Type: application/json" \
-d '{"kind": "password", "password": "your-new-password"}'See Login Methods: Adding a Password for the full flow.
Enforced SSO
If you belong to an organization that enforces SSO, the Change Password form returns a 403 SSO_REQUIRED error. Contact the org Owner for a break-glass exemption if needed.
Password Reset
If you have forgotten your password:
- On the login page, click "Forgot Password?".
- Enter your registered email address and click "Send Reset Link".
- Click the link in the email and enter your new password.
Password reset links expire after approximately one hour and can only be used once.
Merging Two Accounts
If you ended up with two accounts for the same person, you can merge one into the other. The merge re-points everything you own — organizations and roles, projects, services, integrations, API tokens, login methods, and verified email addresses — from the absorbed account onto the survivor account, then retires the absorbed account.
The both-sides-verified flow
The merge only proceeds once both accounts are proven to belong to you:
- Detect candidates. UptimeHunt surfaces accounts you could absorb — a sibling account sharing a verified email address across realms, or a co-member of one of your organizations sharing that verified email. Detection only lists candidates; it never merges anything on its own.
- Review consent. Before anything moves, you see exactly what will be merged (how many organizations, login methods, projects, and API tokens move), which account survives, and a clear statement that the merge is irreversible.
- Prove the other account. You must supply a real credential for the account being absorbed — never just its email address. The consent payload tells you which proof is required via its
proof_requiredfield:- Password account (
proof_required: "password") → re-enter that account's password, passed aspasswordin the confirm body. - Social / SSO account (
proof_required: "sso") → complete a full sign-in round-trip through its identity provider. Start it withPOST /api/v1/auth/merge/sso/start, send the browser to the returnedlogin_url, and after the IdP round-trip you land back at the SPA callback carrying a one-timeproofcode passed assso_proofin the confirm body.
- Password account (
- Confirm. The merge runs in a single atomic step. Live sessions on the absorbed account are signed out, and a confirmation email is sent.
# 1. Detect accounts you could absorb
curl https://app.uptimehunt.io/api/v1/auth/merge/candidates \
-H "Authorization: Bearer {access_token}"
# 2. Review the irreversible-merge consent payload
curl -X POST https://app.uptimehunt.io/api/v1/auth/merge/initiate \
-H "Authorization: Bearer {access_token}" \
-H "Content-Type: application/json" \
-d '{"target_user_id": 4321}'
# 3. Confirm (password proof path)
curl -X POST https://app.uptimehunt.io/api/v1/auth/merge/confirm \
-H "Authorization: Bearer {access_token}" \
-H "Content-Type: application/json" \
-d '{"target_user_id": 4321, "password": "the-other-accounts-password"}'Proving a social/SSO account (the SSO proof leg)
When the account you are absorbing signs in with Google, GitHub, or an organization identity provider, there is no password to verify — you prove ownership by completing a real sign-in round-trip through that identity provider. This adds one endpoint before confirm and changes the confirm body from password to sso_proof:
- Start the proof.
POST /api/v1/auth/merge/sso/startwith the sametarget_user_id. Returns the absorbed account's identity-providerlogin_url. - Complete the IdP round-trip. Send the browser to
login_urland sign in as the absorbed account. After the round-trip, the browser is redirected to the SPA callback with a one-time proof code:…/auth/merge/callback?proof={sso_proof}. - Confirm with the proof. Pass the
proofquery parameter assso_proofin the confirm body.
Choosing which account survives
By default the account you are signed in to is the survivor. If the other account is the sole Owner of a team organization, you are asked to consciously choose which identity survives. When you choose the other account as survivor, pass "survivor": "other" in the confirm body.
The merge is final — there is no undo
A completed merge cannot be reversed. There is no 30-day grace period, no replay, and no self-service "unmerge." The full list of what moved is preserved only in the immutable account.merged audit event for forensics.
Accounts that cannot be merged
A merge is refused when:
- Either side is not email-verified. Both accounts must carry a verified email before they can be combined.
- Either side belongs to a "dedicated accounts" organization. If any organization you (or the other account) belong to has
require_dedicated_accountsturned on, the merge is refused.
Dedicated Accounts Exclusion
An organization can require dedicated accounts (require_dedicated_accounts). When enabled, the organization's members must use separate accounts provisioned through that organization's own SSO realm, and those accounts are excluded from account-merge entirely — they can be neither the survivor nor the absorbed side of a merge.
Per-Member SSO Password Bypass (Break-Glass)
When an organization enforces SSO, password sign-in is normally refused for every member — they must authenticate through the organization's identity provider.
An Owner can grant a single member a password break-glass exemption: a per-member flag that lets that member sign in with a password despite enforced SSO. It exists for documented emergency cases — an admin locked out because the IdP is down, or a service account that cannot perform an interactive SSO login.
- Scope: the exemption applies only to the specific member in the specific organization that granted it.
- Authorization: granting and revoking it requires the Owner-level
sso.editcapability (see the SSO blast-radius note). - Audit: every grant and revoke writes a
member.sso_bypass.granted/member.sso_bypass.revokedaudit event.
# Grant the break-glass exemption (Owner only)
curl -X POST https://app.uptimehunt.io/api/v1/orgs/acme/members/4321/sso-bypass \
-H "Authorization: Bearer {access_token}"
# Revoke it
curl -X DELETE https://app.uptimehunt.io/api/v1/orgs/acme/members/4321/sso-bypass \
-H "Authorization: Bearer {access_token}"Use sparingly
A bypass grant is a hole in your SSO enforcement for one member. Grant it only for a genuine break-glass need, and revoke it once the emergency is over.
Organization Member Email-Domain Policy
An organization can declare an allowlist of email domains its members are allowed to use for their organization-facing email (allowed_member_email_domains).
- Declared list, no DNS verification. This is a plain list of domains the Owner types in — it is not DNS-verified and is entirely separate from the DNS-verified domains used for email routing and from the per-IdP allowed_email_domains JIT allowlist.
- Empty means no filtering. With no domains declared (the default), members may use any email address.
- Enforced when a member sets their email. Existing members are not retroactively touched when the policy is first declared.
Removal Semantics
When a member is removed from (or leaves) an organization, UptimeHunt applies account-level cleanup based on what kind of account the member has:
| Account kind | What removal does |
|---|---|
| Merged account (has more than one login method) | Strips only this organization's SSO login method from the account. The person keeps their account and every other login method. |
| Organization-only JIT account (exists solely as this organization's SSO realm row, no personal organization) | Deletes the whole account — it had no purpose outside this organization. |
| Plain password or social member | Nothing happens to the account; it is independent of the membership. |
Account Security Best Practices
- Use unique passwords not shared with other services.
- Log out when using shared computers.
- Protect your email account — it is your password-reset fallback.
- Report suspicious activity immediately.
Account Deletion
Account deletion is not currently available through the user interface. Contact support to request deletion.
Permanent Action
Account deletion is permanent and cannot be reversed. All services, projects, and historical data will be permanently removed.
Troubleshooting
Cannot Update Profile
- Verify all required fields are completed.
- Check email format is valid.
- Ensure the new email is not already registered.
Password Change Fails
| Issue | Solution |
|---|---|
| "Current password is incorrect" | Verify you're entering the correct current password |
| "Passwords do not match" | Ensure new password and confirmation match exactly |
403 SSO_REQUIRED | Contact the org Owner for a break-glass exemption |
Password Reset Email Not Received
Check spam/junk folders. Wait a few minutes, then request a new reset link.
Account and Organization Basics
Every UptimeHunt account automatically gets a personal organization where you work alone. When you need to collaborate, you create or join a team organization and invite members.
- Personal vs. team organizations — understanding the organization model
- Team organization trials — 14-day free trial for new team organizations
Related Documentation
- Login Methods — add a password, link social sign-in, remove methods
- Email Management — add addresses, set primary, per-org contact email
- Settings
- Registration
- Organizations SSO
- Audit Log
- API Authentication