UptimeHunt Docs
Account

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

  1. Log in to your UptimeHunt account.
  2. Click the user menu in the navigation bar (displays your Gravatar or initials).
  3. Select "Settings" from the dropdown menu.

Updating Your Profile

The Profile tab displays your name, email address, and Gravatar. To update:

  1. Navigate to Settings → Profile tab.
  2. Modify First Name, Last Name, or Email Address as needed.
  3. 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:

  1. Navigate to Settings → Security tab.
  2. Enter your Current Password, New Password, and confirmation.
  3. 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:

  1. On the login page, click "Forgot Password?".
  2. Enter your registered email address and click "Send Reset Link".
  3. 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:

  1. 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.
  2. 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.
  3. 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_required field:
    • Password account (proof_required: "password") → re-enter that account's password, passed as password in the confirm body.
    • Social / SSO account (proof_required: "sso") → complete a full sign-in round-trip through its identity provider. Start it with POST /api/v1/auth/merge/sso/start, send the browser to the returned login_url, and after the IdP round-trip you land back at the SPA callback carrying a one-time proof code passed as sso_proof in the confirm body.
  4. 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:

  1. Start the proof. POST /api/v1/auth/merge/sso/start with the same target_user_id. Returns the absorbed account's identity-provider login_url.
  2. Complete the IdP round-trip. Send the browser to login_url and 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}.
  3. Confirm with the proof. Pass the proof query parameter as sso_proof in 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_accounts turned 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.edit capability (see the SSO blast-radius note).
  • Audit: every grant and revoke writes a member.sso_bypass.granted / member.sso_bypass.revoked audit 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 kindWhat 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 memberNothing 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

IssueSolution
"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_REQUIREDContact 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.

On this page